I found that the security.capability xattr gets lost when cloning a subvolume via btrfs send | btrfs receive. This is easy to reproduce (currently on 3.19.0-rc6, x86_64, with btrfs-progs 3.18.1): Have two btrfs file systems, "/fs1" and "/fs2". # btrfs sub create /fs1/test # touch /fs1/test/foo # setcap cap_net_admin+ep /fs1/test/foo # getcap /fs1/test/foo /fs1/test/foo = cap_net_admin+ep # btrfs prop set /fs1/test ro true # btrfs send /fs1/test | btrfs receive /fs2 # getcap /fs2/test/foo [reports nothing] The cause of the problem seems to be that BTRFS_SEND_C_SET_XATTR comes before BTRFS_SEND_C_CHMOD in the send stream, so that the receiving end will first correctly restore all the xattrs of the file, and after that, perform an lchown() which will cause the kernel to reset the file's capabilities. I don't know how to fix this correctly (especially in the case of incremental sends), so I don't have a patch, but figured it might be useful to share what I found. Regards, Jan -- Jan Andres <jandres@xxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
