* Copying/setting security.selinux xattr explicitly
@ 2016-02-10 10:59 Laurent Bigonville
2016-02-10 14:30 ` Stephen Smalley
0 siblings, 1 reply; 3+ messages in thread
From: Laurent Bigonville @ 2016-02-10 10:59 UTC (permalink / raw)
To: selinux
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Copying/setting security.selinux xattr explicitly
2016-02-10 10:59 Copying/setting security.selinux xattr explicitly Laurent Bigonville
@ 2016-02-10 14:30 ` Stephen Smalley
2016-02-10 14:53 ` Laurent Bigonville
0 siblings, 1 reply; 3+ messages in thread
From: Stephen Smalley @ 2016-02-10 14:30 UTC (permalink / raw)
To: Laurent Bigonville, selinux
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Copying/setting security.selinux xattr explicitly
2016-02-10 14:30 ` Stephen Smalley
@ 2016-02-10 14:53 ` Laurent Bigonville
0 siblings, 0 replies; 3+ messages in thread
From: Laurent Bigonville @ 2016-02-10 14:53 UTC (permalink / raw)
To: selinux
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-02-10 14:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-10 10:59 Copying/setting security.selinux xattr explicitly Laurent Bigonville
2016-02-10 14:30 ` Stephen Smalley
2016-02-10 14:53 ` Laurent Bigonville
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.