btrfs send | btrfs receive adds "security.capability" xattr to some files #292
Comments
|
I don’t have an extensive knowledge of btrfs, and I will let someone more knowledgeable answer, but I mention these two other issues with the inverse issue: #85 and #202. Although, you can provide the relevant lines (or their absence) of the verbose output of receive to better understand the situation: |
|
Hello @Seb35, Here are the (at least seeming to me) relevant lines of the verbose output of btrfs receive: It seems to me that setting the wrong xattrs depends on the received file "before", that is why I have included these in the trace above. Wrong xattrs (i.e. a security.capability is set) are existing for: Rsync comparison: |
|
I was able to do some more experiments and have also created a tiny script with which I can reproduce the issue to 100% on my machine. The kernel versions below are for arch linux vanilla kernel My findings are:
As it seems to me this is dependent on the kernel version, I am creating an issue on the kernel.org bugzilla for this now. |
|
Figured it out. Simply reverting the progs commit could solve the issue, but should compatibility with old kernels be considered? |
|
Yes the compatibility should be considered, there are various combinations of progs/kernel out there. The workaround will be deleted eventually but it seems that now we need to enhance it to work with the new kernel behaviour. I've seen some send+capabilities fstests fail so that seems be still unfixed. Thanks for additional info. |
|
The workaround is going to be deleted in the next release, fixed by patch "btrfs-progs: receive: remove workaround for setting capabilities", the kernel patch has been backported to all live stable kernel versions. |
kdave
pushed a commit
that referenced
this issue
Feb 11, 2021
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>
kdave
pushed a commit
that referenced
this issue
Feb 19, 2021
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>
kdave
pushed a commit
that referenced
this issue
Feb 22, 2021
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On my arch linux built server, I am experiencing inconsistencies with my btrfs volumes and backup strategy using btrfs send | btrfs receive, to be specific, xattrs seem to be added or corrupted for some files.
Environment
System: Arch Linux using
Root is on a btrfs subvolume "@" on a btrfs partition, residing on a luks container on /dev/sda
Snapshots of "@" are created on the "@snapshots" subvolume that is mounted on "/.snapshots"
These snapshots are sent to another "backup" btrfs volume residing on the same PC for backup reasons, consisting of
Problem:
When sending a snapshot from the root btrfs volume to the backup volume using the
btrfs send | btrfs receivecommand chain, some binaries receive xattrs from the security.capability domain.Example (this is also reproducible on my machine):
The text was updated successfully, but these errors were encountered: