When creating a virtual environment with python3 -m venv, the Activate.ps1 script inherits the SELinux security context of the system template directory (e.g., /usr/lib64/python3.14/venv/scripts/common/) rather than the destination project directory. On Fedora, this results in the file being labeled as: system_u:object_r:bin_t:s0 This breaks containerized workflows, where processes run in a restricted shell or use other tools that don't automatically relabel within the container. Reproducible: Always Steps to Reproduce: 1. python3 -m venv .venv 2. ls -lZ .venv/bin/ 3. Note the context of Activate.ps1 in relation to the other files. Actual Results: All files labeled with expected user/project context similar to unconfined_u:object_r:container_file_t:s0 However, Activate.ps1 retains the system binary label: ls -Z .venv/bin/Activate.ps1 system_u:object_r:bin_t:s0 .venv/bin/Activate.ps1 Expected Results: All files created within the .venv directory should inherit the parent directory's context or be labeled according to the user's current security context, allowing standard cleanup (rm -rf) without SELinux intervention. Additional Information: 43 (Workstation Edition) python3-libs-3.14.3-1.fc43.x86_64 SElinux Enforcing
I can reproduce. [~]$ ls -lZ /usr/lib64/python3.14/venv/scripts/common/ .rw-r--r-- 2.2k root system_u:object_r:bin_t:s0 3 Feb 16:32 activate .rw-r--r-- 2.2k root system_u:object_r:bin_t:s0 3 Feb 16:32 activate.fish .rw-r--r-- 9.0k root system_u:object_r:bin_t:s0 3 Feb 16:32 Activate.ps1 [~]$ ls -lZ /usr/lib64/python3.14/venv/scripts/posix/ .rw-r--r-- 937 root system_u:object_r:bin_t:s0 3 Feb 16:32 activate.csh [~]$ python3.14 -m venv ttt [~]$ ls -lZ ttt/bin/ .rw-r--r-- 2.1k churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 activate .rw-r--r-- 907 churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 activate.csh .rw-r--r-- 2.2k churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 activate.fish .rw-r--r-- 9.0k churchyard system_u:object_r:bin_t:s0 3 Feb 16:32 Activate.ps1 .rwxr-xr-x 240 churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 pip .rwxr-xr-x 240 churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 pip3 .rwxr-xr-x 240 churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 pip3.14 lrwxrwxrwx - churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 python -> python3.14 lrwxrwxrwx - churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 python3 -> python3.14 lrwxrwxrwx - churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 python3.14 -> /usr/bin/python3.14 lrwxrwxrwx - churchyard unconfined_u:object_r:user_home_t:s0 2 Mar 12:26 𝜋thon -> python3.14 I think the prolem might be near https://github.com/python/cpython/blob/v3.14.3/Lib/venv/__init__.py#L590 The Activate.ps1 file is the one that is identical and hence is copied by shutil.copy2'ed while the other files are created anew and "only" shutil.copymode'ed.
I think we could use shuitl.copy + shutil.copymode instead of shutil.copy2 to fix this. Either way, we need to report this upstream.
This has been fixed upstream. Considering this was opened with a low severity set, I assume we don't need to backport the fix and can wait for the next upstream release, right?
(In reply to Miro Hrončok from comment #3) > This has been fixed upstream. Considering this was opened with a low > severity set, I assume we don't need to backport the fix and can wait for > the next upstream release, right? No, it isn't urgent. I am fine with waiting for the next upstream release rather than backporting the fix.