Description of problem: xfsdump & xfsrestore fails to preserve unix capabilities. Version-Release number of selected component (if applicable): Current upstream How reproducible: Every time Additional info: While xfsdump/restore does save & re-write file capabilities, it does a chown after capabilities are restored, which causes the kernel to clear all capabilities again. Presumably simply changing the order of chown & capability restore will do the trick.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
An xfstest has been written to demonstrate this but there's no upstream fix yet.
from the xfstest one can see the caps set, then the chown. 3372 open("dumpdir/testfile", O_RDWR|O_CREAT, 0600) = 11 3372 fstat(11, {st_dev=makedev(8, 18), st_ino=4194497, st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2013/09/04-13:09:34, st_mtime=2013/09/04-13:09:34, st_ctime=2013/09/04-13:09:34}) = 0 3372 ftruncate(11, 5) = 0 3372 ioctl(11, 0x401c5820, 0x7fffda1b4c40) = 0 3372 lseek(11, 0, SEEK_SET) = 0 3372 write(11, "test\n", 5) = 5 3372 lsetxattr("dumpdir/testfile", "user.name", "value", 5, 0) = 0 3372 lsetxattr("dumpdir/testfile", "security.capability", "\x01\x00\x00\x02\xc0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = 0 3372 utime("dumpdir/testfile", [2013/09/04-13:09:34, 2013/09/04-13:09:34]) = 0 3372 fchown(11, 0, 0) = 0 3372 fchmod(11, 0100644) = 0 3372 close(11) = 0
Breakpoint 1, 0x00000035b9c033c0 in lsetxattr () from /lib64/libattr.so.1 (gdb) bt #0 0x00000035b9c033c0 in lsetxattr () from /lib64/libattr.so.1 #1 0x00000035b9c02278 in attr_set () from /lib64/libattr.so.1 #2 0x0000000000424d4d in setextattr (path=0x66e370 "dumpdir/testfile", ahdrp=0x6591a0) at content.c:8702 #3 0x0000000000425087 in restore_extattr (drivep=0x657070, fhdrp=<value optimized out>, path=0x66e370 "dumpdir/testfile", ahcs=<value optimized out>, isdirpr=0, onlydoreadpr=0, dah=4294967295) at content.c:8625 #4 0x000000000042f6d1 in applynondirdump (thrdix=0) at content.c:3362 #5 content_stream_restore (thrdix=0) at content.c:2425 #6 0x0000000000419247 in main (argc=6, argv=0x7fffffffe418) at main.c:620 is the path to lsetxattr; Breakpoint 2, 0x00000035b6cdc100 in fchown () from /lib64/libc.so.6 (gdb) bt #0 0x00000035b6cdc100 in fchown () from /lib64/libc.so.6 #1 0x000000000042a87d in restore_complete_reg (strcxtp=0x66e2f0) at content.c:7502 #2 0x000000000042f13d in content_stream_restore (thrdix=0) at content.c:2454 #3 0x0000000000419247 in main (argc=6, argv=0x7fffffffe418) at main.c:620 is the path to fchown.
From a88c49071dde2539cce6d502effc27501416983a Mon Sep 17 00:00:00 2001 From: Dave Chinner <dchinner> Date: Thu, 6 Feb 2014 16:48:39 +1100 Subject: [PATCH] restore: don't trash file capabilities xfsrestore fails to restore file capabilities correctly because it sets the owner on the file after it has restored the capability attributes. This results in the kernel stripping the capabilities when changing the owner of the file and hence the restored file is not complete. Fix this by changing the owner of the file when it is created rather than after it has been fully restored. This ensures we don't kill the caps as they are restored after the owner it appropriately set. This fixes the xfs/296 failure. Signed-off-by: Dave Chinner <dchinner> Reviewed-by: Brian Foster <bfoster> Signed-off-by: Dave Chinner <david> ---
Fix exists upstream but this has been broken forever; we'll pick it up when an upstream release contains the fix. If anyone needs it on a fedora version before that, feel free to re-open this bug & move it to the necessary fedora release. Thanks, -Eric