Xfsdump / restore, Problems with Linux file capabilities

[Dave Chinner]

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?

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com