-
Notifications
You must be signed in to change notification settings - Fork 238
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
capabilities are lost when send/receive #85
Comments
It seems that the XATTR_ITEM is lost. Would you please dump the metadata of the send stream by:
|
Here we go:
|
I guess the problem once again is, that we set_xattr before we chown, so chown wipes all xattr of. |
If you increase verobosity, the capability vs chown will be logged. Once the xattr is detected (https://github.com/kdave/btrfs-progs/blob/master/cmds-receive.c#L856), the contents is saved and applied after chown so it does not get lost. There was no change in that code so I wonder what went wrong. |
|
I think David means add the But at least, the stream is good so only btrfs-progs is involved. |
Everything seems to work. |
I just tried kernel 4.15.15 with btrfs progs 4.15.1 and the capabilities from my example are still not transferred. |
Is your example identical to the commands which I've executed, if yes, then it seems the problem is specific to you. |
Just tried your example on a machine of a colleague. Caps are still missing. |
Well, I didn't use a seperate device for the test. I tried again using a flash drive, did a mkfs.btrfs on it and the caps work there (on both machines).
strace:
|
This seems to be the same issue reported in #202. Can we close this one, and keep track of this issue in that bug? What do you think? Also, I'm currently working to fix this problem. |
Ok, let's use #202 for future discussions of the bug. |
We had a few bugs on the kernel side of send/receive where capabilities ended up being lost after receiving a send stream. They all stem from the fact that the kernel used to send all xattrs before issuing the chown command, and the later clears any existing capabilities in a file or directory. Initially a workaround was added to btrfs-progs' receive command, in commit 123a2a0 ("btrfs-progs: receive: restore capabilities after chown"), and that fixed some instances of the problem. More recently, other instances of the problem were found, a proper fix for the kernel was made, which fixes the root problem by making send always emit the setxattr command for setting capabilities after issuing a chown command. This was done in kernel commit 89efda52e6b693 ("btrfs: send: emit file capabilities after chown"), which landed in kernel 5.8. However, the workaround on the receive command now causes us to incorrectly set a capability on a file that should not have it, because it assumes all setxattr commands for a file always comes before a chown. Example reproducer: $ cat send-caps.sh #!/bin/bash DEV1=/dev/sdh DEV2=/dev/sdi MNT1=/mnt/sdh MNT2=/mnt/sdi mkfs.btrfs -f $DEV1 > /dev/null mkfs.btrfs -f $DEV2 > /dev/null mount $DEV1 $MNT1 mount $DEV2 $MNT2 touch $MNT1/foo touch $MNT1/bar setcap cap_net_raw=p $MNT1/foo btrfs subvolume snapshot -r $MNT1 $MNT1/snap1 btrfs send $MNT1/snap1 | btrfs receive $MNT2 echo echo "capabilities on destination filesystem:" echo getcap $MNT2/snap1/foo getcap $MNT2/snap1/bar umount $MNT1 umount $MNT2 When running the test script, we can see that both files foo and bar get the capability set, when only file foo should have it: $ ./send-caps.sh Create a readonly snapshot of '/mnt/sdh' in '/mnt/sdh/snap1' At subvol /mnt/sdh/snap1 At subvol snap1 capabilities on destination filesystem: /mnt/sdi/snap1/foo cap_net_raw=p /mnt/sdi/snap1/bar cap_net_raw=p Since the kernel fix was backported to all currently supported stable releases (5.10.x, 5.4.x, 4.19.x, 4.14.x, 4.9.x and 4.4.x), remove the workaround from receive. Having such a workaround relying on the order of commands in a send stream is always troublesome and doomed to break one day. A test case for fstests will come soon. Issue: #85 Issue: #202 Issue: #292 Reported-by: Richard Brown <rbrown@suse.de> Reviewed-by: Su Yue <l@damenly.su> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
We had a few bugs on the kernel side of send/receive where capabilities ended up being lost after receiving a send stream. They all stem from the fact that the kernel used to send all xattrs before issuing the chown command, and the later clears any existing capabilities in a file or directory. Initially a workaround was added to btrfs-progs' receive command, in commit 123a2a0 ("btrfs-progs: receive: restore capabilities after chown"), and that fixed some instances of the problem. More recently, other instances of the problem were found, a proper fix for the kernel was made, which fixes the root problem by making send always emit the setxattr command for setting capabilities after issuing a chown command. This was done in kernel commit 89efda52e6b693 ("btrfs: send: emit file capabilities after chown"), which landed in kernel 5.8. However, the workaround on the receive command now causes us to incorrectly set a capability on a file that should not have it, because it assumes all setxattr commands for a file always comes before a chown. Example reproducer: $ cat send-caps.sh #!/bin/bash DEV1=/dev/sdh DEV2=/dev/sdi MNT1=/mnt/sdh MNT2=/mnt/sdi mkfs.btrfs -f $DEV1 > /dev/null mkfs.btrfs -f $DEV2 > /dev/null mount $DEV1 $MNT1 mount $DEV2 $MNT2 touch $MNT1/foo touch $MNT1/bar setcap cap_net_raw=p $MNT1/foo btrfs subvolume snapshot -r $MNT1 $MNT1/snap1 btrfs send $MNT1/snap1 | btrfs receive $MNT2 echo echo "capabilities on destination filesystem:" echo getcap $MNT2/snap1/foo getcap $MNT2/snap1/bar umount $MNT1 umount $MNT2 When running the test script, we can see that both files foo and bar get the capability set, when only file foo should have it: $ ./send-caps.sh Create a readonly snapshot of '/mnt/sdh' in '/mnt/sdh/snap1' At subvol /mnt/sdh/snap1 At subvol snap1 capabilities on destination filesystem: /mnt/sdi/snap1/foo cap_net_raw=p /mnt/sdi/snap1/bar cap_net_raw=p Since the kernel fix was backported to all currently supported stable releases (5.10.x, 5.4.x, 4.19.x, 4.14.x, 4.9.x and 4.4.x), remove the workaround from receive. Having such a workaround relying on the order of commands in a send stream is always troublesome and doomed to break one day. A test case for fstests will come soon. Issue: #85 Issue: #202 Issue: #292 Reported-by: Richard Brown <rbrown@suse.de> Reviewed-by: Su Yue <l@damenly.su> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
We had a few bugs on the kernel side of send/receive where capabilities ended up being lost after receiving a send stream. They all stem from the fact that the kernel used to send all xattrs before issuing the chown command, and the later clears any existing capabilities in a file or directory. Initially a workaround was added to btrfs-progs' receive command, in commit 123a2a0 ("btrfs-progs: receive: restore capabilities after chown"), and that fixed some instances of the problem. More recently, other instances of the problem were found, a proper fix for the kernel was made, which fixes the root problem by making send always emit the setxattr command for setting capabilities after issuing a chown command. This was done in kernel commit 89efda52e6b693 ("btrfs: send: emit file capabilities after chown"), which landed in kernel 5.8. However, the workaround on the receive command now causes us to incorrectly set a capability on a file that should not have it, because it assumes all setxattr commands for a file always comes before a chown. Example reproducer: $ cat send-caps.sh #!/bin/bash DEV1=/dev/sdh DEV2=/dev/sdi MNT1=/mnt/sdh MNT2=/mnt/sdi mkfs.btrfs -f $DEV1 > /dev/null mkfs.btrfs -f $DEV2 > /dev/null mount $DEV1 $MNT1 mount $DEV2 $MNT2 touch $MNT1/foo touch $MNT1/bar setcap cap_net_raw=p $MNT1/foo btrfs subvolume snapshot -r $MNT1 $MNT1/snap1 btrfs send $MNT1/snap1 | btrfs receive $MNT2 echo echo "capabilities on destination filesystem:" echo getcap $MNT2/snap1/foo getcap $MNT2/snap1/bar umount $MNT1 umount $MNT2 When running the test script, we can see that both files foo and bar get the capability set, when only file foo should have it: $ ./send-caps.sh Create a readonly snapshot of '/mnt/sdh' in '/mnt/sdh/snap1' At subvol /mnt/sdh/snap1 At subvol snap1 capabilities on destination filesystem: /mnt/sdi/snap1/foo cap_net_raw=p /mnt/sdi/snap1/bar cap_net_raw=p Since the kernel fix was backported to all currently supported stable releases (5.10.x, 5.4.x, 4.19.x, 4.14.x, 4.9.x and 4.4.x), remove the workaround from receive. Having such a workaround relying on the order of commands in a send stream is always troublesome and doomed to break one day. A test case for fstests will come soon. Issue: #85 Issue: #202 Issue: #292 Reported-by: Richard Brown <rbrown@suse.de> Reviewed-by: Su Yue <l@damenly.su> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
This bug is probably a regression: https://bugzilla.kernel.org/show_bug.cgi?id=68891
btrfs-progs: 4.14
kernel 4.14.14 (on Archlinux)
For the original fs and a readonly snapshot, I get:
After send/receive:
The text was updated successfully, but these errors were encountered: