python -m venv incorrectly preserves bin_t SELinux context on Activate.ps1 from system templates

[hroncok]

Bug report

Bug description:

As reported in Fedora in https://bugzilla.redhat.com/show_bug.cgi?id=2443703

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.

Reproducer (on Fedora):

[~]$ 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

Note namely .rw-r--r-- 9.0k churchyard system_u:object_r:bin_t:s0 3 Feb 16:32 Activate.ps1.

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 while the other files are created anew and "only" shutil.copymodeed.

I think we could use shuitl.copy + shutil.copymode instead of shutil.copy2 to fix this. I can submit a PR.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

[hroncok]

I wonder, however, how to test this properly in the tests :/

[hroncok]

I have this as a fix, but I need to figure out the best way to assert this in tests where the files in Lib/venv likely do not have bin_t SELinux context at all :(

Perhaps I can just assert the mtime of all the files.

diff --git a/Lib/venv/__init__.py b/Lib/venv/__init__.py
index 19eddde700b..daac0559427 100644
--- a/Lib/venv/__init__.py
+++ b/Lib/venv/__init__.py
@@ -581,11 +581,11 @@ def skip_file(f):
                                    'may be binary: %s', srcfile, e)
                     continue
                 if new_data == data:
-                    shutil.copy2(srcfile, dstfile)
+                    shutil.copy(srcfile, dstfile)
                 else:
                     with open(dstfile, 'wb') as f:
                         f.write(new_data)
-                    shutil.copymode(srcfile, dstfile)
+                shutil.copymode(srcfile, dstfile)
 
     def upgrade_dependencies(self, context):
         logger.debug(