From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0001.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0002.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0003.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0004.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0005.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0006.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0007.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0008.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0009.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0010.bin>

From shamaz.mazum at gmail.com  Thu Oct  1 09:08:00 2015
From: shamaz.mazum at gmail.com (Vasily Postnicov)
Date: Thu, 1 Oct 2015 19:08:00 +0300
Subject: HAMMER per-PFS permissions for ioctl syscalls
Message-ID: <CADnZ6B=ZRwpC=a=1jzakQx_8KRn5bnzbmPucEkC0xCg7XTLG1A@mail.gmail.com>

Ok, let it be as you decide. But maybe this last argument will change your
mind. Imagine a user who has two machines, say, A and B. The machine A has
a PFS mounted to /home (or /home/user) and B has a slave mirror of that PFS
mounted to /backup/user. If that user wants to update his mirror on B, he
must login as root and launch 'hammer mirror-copy /home/user
B:/backup/user' which means he must run hammer utility as root and also ssh
as root on both machines. Is it 100% secure to have a root access over ssh?
Has not ssh any yet unseen bugs? I propose something like that:

On A:
su                            (it will be necessary as only root has the
right to change permissions)
<root password>
hammer -u user add-perm /home mirror-read

On B:
su
<root password>
hammer -u user add-perm /backup/home mirror-write

And now the mirror can be updated not only by root, but also by user. As
the permissions are set on per-PFS basis, user will not be able to make a
mirror of any PFS, but only of his own home. zfs allow/unallow works the
same way.

Here is a r?sum?:
1) Only root has the right to change permissions.
2) Only root has the right to make any changes to filesystem, which are not
on per-PFS basis (like volume management, upgrading filesystem to a new
version).
3) Permissions a per-PFS.

I attach a proof-of-concept. Apply this patch to DragonFly_RELEASE_4_0. You
will be able to set the following permissions: mirror-read, mirror-write,
snap-add, snap-del as shown above. Three new commands are added to hammer
utility: add-perm, del-perm, show-perm. Let me know, if you are interested.

2015-10-01 6:56 GMT+03:00 Matthew Dillon <dillon at backplane.com>:

> Well, I think its a bit too dangerous to give snapshotting power to the
> user in this case.  The snapshots are managed on a per-PFS  basis so the
> user would be able to interfere with whatever root intended on doing with
> the capability.
>
> -Matt
>
> On Sat, Sep 26, 2015 at 7:06 AM, Vasily Postnicov <shamaz.mazum at gmail.com>
> wrote:
>
>> Hello. I have noticed, that some ioctls, like HAMMERIOC_GETHISTORY or
>> HAMMERIOC_GET_INFO can be made by any user, and there are some like
>> HAMMERIOC_ADD_SNAPSHOT, which only root can do. I find this somewhat
>> "unfair", because why a user cannot, for example, make a snapshot of his
>> own home directory, if there is a PFS mounted to that directory? I think
>> something like zfs allow/unallow is needed here. Any ideas how I can
>> implement this?
>>
>> Maybe I should add a new record type to vfs/hammer/hammer_disk.h, say
>> HAMMER_RECTYPE_PERM, and use it in the similar way to
>> HAMMER_RECTYPE_CONFIG, like writing functions similar to
>> hammer_ioc_get/set_config? So when a user calls ioctl() it will be like
>> this in the kernel space:
>>
>> 1) Start a new transactions and initialize a cursor.
>> 2) setup the cursor. Set cursor.key_beg.rec_type = HAMMER_RECTYPE_PERM;
>> 3) do hammer_btree_lookup(&cursor);
>> 4) If lookup succeeded, extract permission info and act accordingly to it.
>>
>> So what you think? Will it work? Maybe I need to cache the results
>> somehow and do not call hammer_btree_lookup() each time ioctl is called? Or
>> it is already done automatically?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.patch
Type: text/x-patch
Size: 27811 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20151001/935be955/attachment-0011.bin>