xfs
[Top] [All Lists]

Re: Xfsdump / restore, Problems with Linux file capabilities

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Xfsdump / restore, Problems with Linux file capabilities
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 03 Jan 2013 17:44:46 -0600
Cc: fugazzi® <fugazzi99@xxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20130103233217.GJ3120@dastard>
References: <2623173.XhKSAea7qn@orione> <50DF4DC1.8000200@xxxxxxxxxxx> <50E60CEA.9040002@xxxxxxxxxxx> <20130103233217.GJ3120@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
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.
> 

<Prev in Thread] Current Thread [Next in Thread>