Bug 2443703

Summary: python3 -m venv incorrectly preserves bin_t SELinux context on Activate.ps1 from system templates
Product: [Fedora] Fedora Reporter: Alistair Lewars <alistair.lewars>
Component: python3.14Assignee: Miro Hrončok <mhroncok>
Status: ASSIGNED --- QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: 43CC: ksurma, mhroncok, python-maint, python-packagers-sig
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alistair Lewars 2026-03-01 21:01:45 UTC 
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
Comment 1 Miro Hrončok 2026-03-02 11:45:53 UTC 
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.
Comment 2 Miro Hrončok 2026-03-02 11:47:44 UTC 
I think we could use shuitl.copy + shutil.copymode instead of shutil.copy2 to fix this. Either way, we need to report this upstream.