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

[Stephen Smalley]

Post by 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?

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.

[Laurent Bigonville]

Post by Stephen Smalley

Post by 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?

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