Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Incremental receives can destroy snapshots without the destroy permission #16943

Open
randomnetcat opened this issue Jan 12, 2025 · 1 comment · May be fixed by #16991 or #17015
Open

Incremental receives can destroy snapshots without the destroy permission #16943

randomnetcat opened this issue Jan 12, 2025 · 1 comment · May be fixed by #16991 or #17015
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@randomnetcat
Copy link

System information

Type Version/Name
Distribution Name NixOS
Distribution Version 25.05.20250108.bffc22e (Warbler)
Kernel Version 6.6.69
Architecture x86_64
OpenZFS Version zfs-2.2.7-1

Describe the problem you're observing

If a user is delegated the receive permission, they can use zfs receive -F on that dataset to destroy snapshots, even when they have not been granted the rollback or destroy permission on the same dataset.

This may be as intended, but it is extremely surprising to me as a user. At the very least, the documentation should be updated to make this clear.

Describe how to reproduce the problem

# As root:
zfs create rpool/test
zfs create rpool/test/src
zfs create rpool/test/dest
zfs allow -u user send,snapshot,receive,mount,hold,create rpool/test

# As user:
zfs snapshot rpool/test/src@a
zfs send -R rpool/test/src@a | zfs receive rpool/dest
zfs snapshot rpool/test/src@b
zfs snapshot rpool/test/dest@x
zfs send -I rpool/test/src@a rpool/test/src@b | zfs receive -F rpool/test/dest

Results: rpool/test/dest has two snapshots, @a and @b. rpool/test/dest@x has been destroyed, despite the fact that user did not have permission to destroy it directly. I would expect that user does not have a way to do this.
@randomnetcat randomnetcat added the Type: Defect Incorrect behavior (e.g. crash, hang) label Jan 12, 2025
@shodanshok
Copy link
Contributor

shodanshok commented Jan 24, 2025 •
edited
Loading

I agree: force receive basically allows rollbacks on destination pools where no rollback permission was granted.

This seems wrong - should zfs receive -F depend on explicit rollback permission being granted via zfs allow?

shodanshok added a commit to shodanshok/zfs that referenced this issue Jan 26, 2025
@shodanshok
require rollback permission when force receive
907d712 
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 add the rollback permission requirement for forced receive.

Fixes openzfs#16943

Signed-off-by: Gionatan Danti <[email protected]>
@shodanshok shodanshok linked a pull request Jan 26, 2025 that will close this issue
Open
13 tasks
shodanshok added a commit to shodanshok/zfs that referenced this issue Jan 29, 2025
@shodanshok
require rollback permission when force receive
c3a7dba 
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 add the rollback permission requirement for force receive.
To avoid changing current default behavior, a new zfs_recv_perm tunable
is introduced. When set to 0 (default) the new permission check is
disabled. When set to 1 rollback permission requirement is
enabled.

Fixes openzfs#16943

Signed-off-by: Gionatan Danti <[email protected]>
shodanshok added a commit to shodanshok/zfs that referenced this issue Jan 31, 2025
@shodanshok
require rollback permission when force receive
30edc15 
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 add the rollback permission requirement for force receive.
To avoid changing current default behavior, a new tunable
zfs_recv_force_needs_perm is introduced. When set to 0 (default) the
new permission check is disabled. When set to 1 rollback permission
requirement is enabled.

Fixes openzfs#16943

Signed-off-by: Gionatan Danti <[email protected]>
shodanshok added a commit to shodanshok/zfs that referenced this issue Jan 31, 2025
@shodanshok
require rollback permission when force receive
ab63717 
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 add the rollback permission requirement for force receive.
To avoid changing current default behavior, a new tunable
zfs_recv_force_needs_perm is introduced. When set to 0 (default) the
new permission check is disabled. When set to 1 rollback permission
requirement is enabled.

Fixes openzfs#16943

Signed-off-by: Gionatan Danti <[email protected]>
shodanshok added a commit to shodanshok/zfs that referenced this issue Jan 31, 2025
@shodanshok
Add append permission for limited receive
5f6c331 
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 openzfs#16943

Signed-off-by: Gionatan Danti <[email protected]>
@shodanshok shodanshok linked a pull request Jan 31, 2025 that will close this issue
Open
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Milestone
No milestone
2 participants
@randomnetcat @shodanshok