[issue38893] broken container/selinux integration

Christian Heimes added the comment: I have created a new PR that introduces preserve_security_context argument and changes the default behavior of copy operations. All copy operations behave now similar to "cp -p --preserve=xattr" by default. copy2(src, dst, preserve_security_context=True) r

[issue38893] broken container/selinux integration

Change by Christian Heimes : -- pull_requests: +22580 pull_request: https://github.com/python/cpython/pull/23720 ___ Python tracker ___

[issue38893] broken container/selinux integration

Enrico Scholz added the comment: IMO the SELinux security attributes must not be copied (except when requested explicitly). Doing so will create badly labeled systems else. It would be better to use default transition rules and call optionally selinux_restorecon() then. E.g. when copying

[issue38893] broken container/selinux integration

Change by Christian Heimes : -- keywords: +patch pull_requests: +20577 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21430 ___ Python tracker ___

[issue38893] broken container/selinux integration

Change by Christian Heimes : -- assignee: -> christian.heimes versions: +Python 3.10 -Python 3.7 ___ Python tracker ___ ___ Python-

[issue38893] broken container/selinux integration

Christian Heimes added the comment: The issue came up at $WORK now. Core utils like copy command ignore "security.selinux" xattr unless the user explicitly asks to preserve the security context, see https://github.com/coreutils/coreutils/blob/6a3d2883fed853ee01079477020091068074e12d/src/copy

[issue38893] broken container/selinux integration

Christian Heimes added the comment: No, CPython's stdlib doesn't use libselinux. I talked to an engineer from Red Hat's SELinux team today. SELinux returns EACCES for policy violations like in this case. The _copyxattr() helper function ignores EPERM but not EACCES. You are seeing a Permissi

[issue38893] broken container/selinux integration

Leif Middelschulte added the comment: @Christian Heimes: is there anything else you need from me? Is this the wrong forum? As discussed in the referenced GitHub issue, some SELinux people suggest it might be a fault in how Python determines (?) it's running within a container environment an

[issue38893] broken container/selinux integration

Leif Middelschulte added the comment: For the sake of completeness, the content of `/tmp/test.py`: ``` #!/usr/bin/env python3 from shutil import copy2 copy2('/tmp/some_file', '/relabel_bug/failure') ``` -- ___ Python tracker

[issue38893] broken container/selinux integration

Leif Middelschulte added the comment: > Could you please provide name and value of the setxattr() call? I bet it's > trying to setxattr 'security.selinux' extended file attribute. (Pdb) bt full /usr/lib64/python3.7/pdb.py(1701)main() -> pdb._runscript(mainpyfile) /usr/lib64/python3.7/pdb.

[issue38893] broken container/selinux integration

Christian Heimes added the comment: >From the Github bug: copy2() fails while copying extended attributes. # python3 Python 3.7.4 (default, Aug 12 2019, 14:45:07) [GCC 9.1.1 20190605 (Red Hat 9.1.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import

[issue38893] broken container/selinux integration

New submission from Leif Middelschulte : It seems Python does not necessarily determine that it is running inside a container correctly. This leads to broken/unexpected behavior when trying to copy files across filesytems using `copy2`. This directly affects Python3 inside the official `fedor