On Fri, May 08, 2020 at 04:54:36PM -0300, Marcos Paulo de Souza wrote: > From: Marcos Paulo de Souza <mpdesouza@xxxxxxxx> > > [PROBLEM] > Whenever a chown is executed, all capabilities of the file being touched are > lost. When doing incremental send with a file with capabilities, there is a > situation where the capability can be lost in the receiving side. The > sequence of actions bellow shows the problem: > > $ mount /dev/sda fs1 > $ mount /dev/sdb fs2 > > $ touch fs1/foo.bar > $ setcap cap_sys_nice+ep fs1/foo.bar > $ btrfs subvol snap -r fs1 fs1/snap_init > $ btrfs send fs1/snap_init | btrfs receive fs2 > > $ chgrp adm fs1/foo.bar > $ setcap cap_sys_nice+ep fs1/foo.bar > > $ btrfs subvol snap -r fs1 fs1/snap_complete > $ btrfs subvol snap -r fs1 fs1/snap_incremental > > $ btrfs send fs1/snap_complete | btrfs receive fs2 > $ btrfs send -p fs1/snap_init fs1/snap_incremental | btrfs receive fs2 > > At this point, only a chown was emitted by "btrfs send" since only the group > was changed. This makes the cap_sys_nice capability to be dropped from > fs2/snap_incremental/foo.bar > > [FIX] > Only emit capabilities after chown is emitted. The current code > first checks for xattrs that are new/changed, emits them, and later emit > the chown. Now, __process_new_xattr skips capabilities, letting only > finish_inode_if_needed to emit them, if they exist, for the inode being > processed. > > This behavior was being worked around in "btrfs receive" > side by caching the capability and only applying it after chown. Now, > xattrs are only emmited _after_ chown, making that hack not needed > anymore. > > Link: https://github.com/kdave/btrfs-progs/issues/202 > Suggested-by: Filipe Manana <fdmanana@xxxxxxxx> > Reviewed-by: Filipe Manana <fdmanana@xxxxxxxx> > Signed-off-by: Marcos Paulo de Souza <mpdesouza@xxxxxxxx> > --- <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter>
