Copying/setting security.selinux xattr explicitly

Copying/setting security.selinux xattr explicitly

[Laurent Bigonville]

Hello,

I've a question concerning copying the security.selinux xattr explicitly.

In you opinion what should happen in an implementation if it cannot be 
reset security.selinux on the target file?

Apparently GNU cp -a ignore failures (while cp --preserve=context fails).

In some python helper function (_copyxattr(), see 
https://bugs.python.org/issue14082), it will return an exception if the 
copy of any of the xattr is failing, there is no special case for 
security.selinux.

What do you think should be the behavior here?

Cheers,

Laurent Bigonville

Re: Copying/setting security.selinux xattr explicitly

[Stephen Smalley]

On 02/10/2016 05:59 AM, Laurent Bigonville wrote:
> Hello,
>
> I've a question concerning copying the security.selinux xattr explicitly.
>
> In you opinion what should happen in an implementation if it cannot be
> reset security.selinux on the target file?
>
> Apparently GNU cp -a ignore failures (while cp --preserve=context fails).
>
> In some python helper function (_copyxattr(), see
> https://bugs.python.org/issue14082), it will return an exception if the
> copy of any of the xattr is failing, there is no special case for
> security.selinux.
>
> What do you think should be the behavior here?

The rationale for the difference in behavior between cp -a and cp 
--preserve=context is that cp -a usage predates SELinux (and extended 
attributes) and treating the inability to set the SELinux attribute on 
the destination file as a hard failure would have broken many existing 
uses of cp -a.

That is in fact generally true for all extended attributes, since trying 
to set any of them could fail due to lack of permission (except perhaps 
user.*) or due to lack of extended attribute support in the destination 
filesystem.

Looking at the patches in the bug/issue you cited, it looks like they 
actually ignore errno.EPERM, errno.ENOTSUP, and errno.ENODATA.  So the 
only one they don't ignore that SELinux might return would be errno.EACCES.

I'm a bit unclear on the intended semantics of shutil.copy2(), as on the 
one hand they say it is supposed to be like cp -p (which does not copy 
extended attributes at all) but on the other hand they now say that it 
copies all metadata that it can.

Re: Copying/setting security.selinux xattr explicitly

[Laurent Bigonville]

Le 10/02/16 15:30, Stephen Smalley a écrit :
> On 02/10/2016 05:59 AM, Laurent Bigonville wrote:
>> Hello,
>>
>> I've a question concerning copying the security.selinux xattr 
>> explicitly.
>>
>> In you opinion what should happen in an implementation if it cannot be
>> reset security.selinux on the target file?
>>
>> Apparently GNU cp -a ignore failures (while cp --preserve=context 
>> fails).
>>
>> In some python helper function (_copyxattr(), see
>> https://bugs.python.org/issue14082), it will return an exception if the
>> copy of any of the xattr is failing, there is no special case for
>> security.selinux.
>>
>> What do you think should be the behavior here?
>
> The rationale for the difference in behavior between cp -a and cp 
> --preserve=context is that cp -a usage predates SELinux (and extended 
> attributes) and treating the inability to set the SELinux attribute on 
> the destination file as a hard failure would have broken many existing 
> uses of cp -a.
>
> That is in fact generally true for all extended attributes, since 
> trying to set any of them could fail due to lack of permission (except 
> perhaps user.*) or due to lack of extended attribute support in the 
> destination filesystem.
>
> Looking at the patches in the bug/issue you cited, it looks like they 
> actually ignore errno.EPERM, errno.ENOTSUP, and errno.ENODATA.  So the 
> only one they don't ignore that SELinux might return would be 
> errno.EACCES.
>
> I'm a bit unclear on the intended semantics of shutil.copy2(), as on 
> the one hand they say it is supposed to be like cp -p (which does not 
> copy extended attributes at all) but on the other hand they now say 
> that it copies all metadata that it can.
>
Not too sure either.

I've proposed them to either ignore error when the xattr is 
security.selinux or ignore EACCES errors altogether.

See: https://bugs.python.org/issue26328