Add receive:append permission for limited receive #17015
Conversation
There was a problem hiding this comment.
I don't think I like the permission named just "append", not some "receive:append" or something like that, what is allowed by the command syntax. Also as I have told before, it would be nice to investigate other related cases, like receive with rollback to the last snapshot, and think about similar permissions for the rollback command.
shodanshok
force-pushed
the
permission
branch
from
5f6c331 to
1630953
Compare
I changed the permission name to
While true, I feel this would significantly increase the scope of this patch, which really is about providing a simple solution to the security issue we have now (and between a module tunable and this new permission I prefer the latter). |
shodanshok
changed the title
shodanshok
force-pushed
the
permission
branch
from
1630953 to
0d9c37f
Compare
|
After catching up on the discussion in #16991 this does seem like the best way forward. As part of this PR can you'll need to extend the delegation tests accordingly, |
shodanshok
force-pushed
the
permission
branch
from
0d9c37f to
f67cc2a
Compare
shodanshok
force-pushed
the
permission
branch
from
f67cc2a to
47722de
Compare
I added a basic test. This is my first try with the test suite, I hope the test is working as expected. |
shodanshok
force-pushed
the
permission
branch
2 times, most recently
from
1a31166 to
721c5e3
Compare
| log_must_busy zfs destroy -rf $dtst | ||
|
|
||
| log_must zfs allow $user create,mount,canmount $fs | ||
| user_run $user eval "zfs receive -o canmount=off -F $dtst < $bak_user" |
There was a problem hiding this comment.
Could/chould we check for error here and below?
There was a problem hiding this comment.
I am unsure, as the receive test (which I copied) does not check for such errors.
There was a problem hiding this comment.
I haven't looked how to do it, but I find weird that we verify command error not by its explicit exit status, but by expected result of its work. Would be good to check both.
tests/zfs-tests/tests/functional/delegate/delegate_common.kshlib
Outdated
Show resolved
Hide resolved
|
@shodanshok Please rebase this to the latest master, or it won't pass CI tests on Fedora due to their kernel update. |
Force receive (zfs receive -F) can rollback or destroy snapshots and file systems that do not exist on the sending side (see zfs-receive man page). This means an user having the receive permission can effectively delete data on receiving side, even if such user does not have explicit rollback or destroy permissions. This patch adds the receive:append permission, which only permits limited, non-forced receive. Behavior for users with full receive permission is not changed in any way. Fixes openzfs#16943 Signed-off-by: Gionatan Danti <[email protected]>
Force receive (zfs receive -F) can rollback or destroy snapshots and file systems that do not exist on the sending side (see zfs-receive man page). This means an user having the receive permission can effectively delete data on receiving side, even if such user does not have explicit rollback or destroy permissions.
This patch adds the append permission, which only permits limited, non-forced receive. Behavior for users with full receive permission is not changed in any way.
Fixes #16943
Motivation and Context
Description
How Has This Been Tested?
Types of changes
Checklist:
Signed-off-by.