On 1/3/13 5:32 PM, Dave Chinner wrote: > On Thu, Jan 03, 2013 at 04:57:46PM -0600, Eric Sandeen wrote: >> On 12/29/12 2:08 PM, Eric Sandeen wrote: >>> 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. >> >> Ok, here's what's going on; during the restore the cap does get >> set: >> >> xfs_xattr_set/xfsrestore: name is capability, value is >> xfs_xattr_set/xfsrestore: returns 0 >> >> but then it gets removed again: >> >> xfs_xattr_set/xfsrestore: name is capability, value is (null) >> xfs_xattr_set/xfsrestore: no value, removing, returning 0 Pid: >> 18041, comm: xfsrestore Tainted: GF O 3.8.0-rc2 #2 Call >> Trace: [<ffffffffa028de68>] xfs_xattr_set+0x118/0x120 [xfs] >> [<ffffffff8119a8c0>] generic_removexattr+0x80/0x90 >> [<ffffffff8120b408>] cap_inode_killpriv+0x28/0x30 >> [<ffffffff8120c666>] security_inode_killpriv+0x16/0x20 >> [<ffffffff81192edf>] notify_change+0x18f/0x330 >> [<ffffffff81176b70>] chown_common+0x60/0xa0 [<ffffffff81176c30>] >> sys_fchown+0x80/0xd0 [<ffffffff81537c59>] >> system_call_fastpath+0x16/0x1b >> >> so xfsrestore does set the capability, but then it does a chown >> which triggers security_inode_killpriv() and removes it again. >> \o/ >> >> perhaps we just need to swap the order of the xattr restores and >> the chowns in the xfsrestore process. > > If that's the case, then this has been broken for a long while, > right? I take it we don't have any xfsdump/restore tests that check > for capabilities being correctly restored? Nope, but I've written one to be sent shortly. It could be added to an existing test but I figure we don't want to do that... -Eric > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs