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.

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

'zfs send -I' should not require 'hold' permission on src dataset if using 'zfs allow' delegation mechanism #16394

Open
whoschek opened this issue Jul 28, 2024 · 0 comments
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@whoschek
Copy link

whoschek commented Jul 28, 2024

System information

FreeBSD:
zfs-2.1.14-FreeBSD_gd99134be8 (FreeBSD freebsd 13.3-RELEASE FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64)
zfs-2.2.4-FreeBSD_g256659204 (FreeBSD freebsd 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64)

Linux:
zfs-2.2.5~rc7-noble1 (Ubuntu 24.04)
zfs-2.2.2-0ubuntu9 (Ubuntu 24.04)
zfs-2.1.5-1ubuntu6~22.04.4 (Ubuntu 22.04)

Describe the problem you're observing

In my testing I discovered that, on Linux and FreeBSD, the 'send' permission is sufficient for 'zfs send -i' to succeed if the 'zfs allow' delegation mechanism is used to grant permissions to a non-root user (which is expected), whereas for 'zfs send -I' (note the uppercase I) an additional 'hold' permission is required as well (which isn't expected). Otherwise the following error happens on zfs send -I wb_src/tmp@u1 wb_src/tmp@u3

cannot hold: permission denied

The hold permission should not be required. Presumably, the implementation of 'zfs send' intermittently uses a hold but that should better not bubble up to the level of affecting user level permission requirements.

Interestingly, a version with -i (skip intermediate snapshots) instead of -I (include intermediate snapshots) does not fail:
zfs send -i wb_src/tmp@u1 wb_src/tmp@u3 # does not fail

Describe how to reproduce the problem

Here is a reliable minimal reproducer:

sudo zpool destroy -f wb_src
dd if=/dev/zero of=/tmp/wb_src bs=1024 count=102400  # create empty 100MB test file
sudo zpool create wb_src /tmp/wb_src
sudo zfs create -p -u wb_src/tmp
sudo zfs snapshot wb_src/tmp@u1
sudo zfs snapshot wb_src/tmp@u2
sudo zfs snapshot wb_src/tmp@u3

#sudo zfs allow -u $USER send,hold wb_src # use this to make the 'zfs send' succeed
sudo zfs allow -u $USER send wb_src # use this to make the 'zfs send' fail

#The following command fails with
#cannot hold: permission denied
#cannot send 'wb_src/tmp': permission denied
zfs send -I wb_src/tmp@u1 wb_src/tmp@u3 > /tmp/out

#Interestingly, a version with -i (skip intermediate snapshots) instead of -I (include intermediate snapshots) does not fail:
zfs send -i wb_src/tmp@u1 wb_src/tmp@u3 > /tmp/out # does not fail

The exact versions of zfs/FreeBSD/Linux that were tested are listed above.

Include any warning/errors/backtraces from the system logs

@whoschek whoschek added the Type: Defect Incorrect behavior (e.g. crash, hang) label Jul 28, 2024
whoschek added a commit to whoschek/bzfs that referenced this issue Jul 28, 2024
whoschek added a commit to whoschek/bzfs that referenced this issue Jul 28, 2024
whoschek added a commit to whoschek/bzfs that referenced this issue Jul 28, 2024
whoschek added a commit to whoschek/bzfs that referenced this issue Jul 28, 2024
whoschek added a commit to whoschek/bzfs that referenced this issue Jul 28, 2024
@whoschek whoschek changed the title 'zfs send' on Linux should not require 'hold' permission on src dataset if using 'zfs allow' delegation mechanism 'zfs send -I' on Linux should not require 'hold' permission on src dataset if using 'zfs allow' delegation mechanism Jul 28, 2024
@whoschek whoschek changed the title 'zfs send -I' on Linux should not require 'hold' permission on src dataset if using 'zfs allow' delegation mechanism 'zfs send -I' should not require 'hold' permission on src dataset if using 'zfs allow' delegation mechanism Aug 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

No branches or pull requests

1 participant