Xfsdump / restore, Problems with Linux file capabilities
Eric Sandeen
sandeen at sandeen.net
Sat Dec 29 14:08:33 CST 2012
On 12/29/12 12:41 PM, fugazzi® wrote:
> Hi everyone, I had a problem with xfsrestore not restoring Linux capabilities
> on my system.
>
> If I do "getcap ping" on my XFS file-system I normally get:
> /usr/bin/ping = cap_net_raw+ep.
>
> On the contrary, after a restore I get nothing, the capability is gone.
> I tried with posix acls and they got restored correctly so the problem seems
> to be only connected with capabilities.
> This is annoying because after a restore I have to remember to re install the
> packages that used capabilities to have them back on, otherwise no ping with
> normal user for example.
>
> I use Arch Linux 64 bit with kernel 3.7.1 vanilla on a core2 quad system.
>
> Hope this will be of help,
> Thank you,
> Fugazzi
I get the same thing on my RHEL6 box FWIW; I'll try to look into it.
With max verbosity during the dump, I see:
xfsdump: dumping non-root extended attributes for nondir ino 131
xfsdump: dumping root extended attributes for nondir ino 131
xfsdump: dumping secure extended attributes for nondir ino 131
xfsdump: building extattr record sz 48 hdrsz 16 namesz 11 (capability) valsz 20
xfsdump: xlate_extattrhdr
xfsdump: building extattr record sz 64 hdrsz 16 namesz 8 (selinux) valsz 38
xfsdump: xlate_extattrhdr
xfsdump: drive_simple get_write_buf( want 112 )
xfsdump: drive_simple write( offset 21336 (0x5358 051530) size 112 (0x70 0160) )
xfsdump: dumping NULL extattrhdr
xfsdump: xlate_extattrhdr
so it does see the capability attr at dump time. During restore, I see:
xfsrestore: read extattr hdr sz 48 valoff 27 flags 0x8 valsz 20 cs 0x0
...
xfsrestore: read extattr hdr sz 64 valoff 24 flags 0x8 valsz 38 cs 0x0
so it sees xattrs of the proper sizes in the dump.
And tracing the xfsrestore I do see:
16735 lsetxattr("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
16735 lsetxattr("testfile", "security.selinux", "unconfined_u:object_r:admin_home_t:s0", 38, 0) = 0
so it seems to be attempting to restore both as well, and the values are the same as what I see from tracing "setcap" - and upposedly the lsetxattr succeeded, so don't know why we don't see it in the resulting file.
I'll keep looking into it.
More information about the xfs
mailing list