This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: multiprocessing processes seem to "bleed" user information (GID/UID/groups)
Type: behavior Stage: resolved
Components: Documentation, Library (Lib) Versions: Python 3.7, Python 3.6
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, romanofski, zerg
Priority: normal Keywords:

Created on 2019-12-04 05:34 by romanofski, last changed 2022-04-11 14:59 by admin. This issue is now closed.

File name Uploaded Description Edit romanofski, 2019-12-04 05:34
Messages (2)
msg357773 - (view) Author: Roman Joost (romanofski) Date: 2019-12-04 05:34
When running a process which changes UID/GID, some of the following processes will run as the user I change to per process.

In order to reproduce (see the attached reproducer):
1. Change the 'USERNAME' to an unprivileged user on your system.
2. Run the reproducer as a user with elevated privileges (e.g. root or some secondary user you have on your system). Mind you, I don't think the user you run as needs elevated privileges, but that's the user I ran as when I observed this behaviour.
3. The reproducer iterates over a list (It stems from a test function which was checking permissions on log files). Observe the print out, which prints the process' GID, UID and secondary groups before we're changing to the users GID, UID and secondary groups.
4. You should observe that at some point the process prints the user information of the user we want to change to not the one which initially started the script.

Example output when running locally as root:

('B', (0, 0, [0]))
('A', (0, 0, [0]))
('C', (0, 0, [0]))
('E', (0, 0, [0]))
('D', (0, 0, [0]))
('F', (1002, 1002, [10, 135, 1000, 1002]))
('H', (1002, 1002, [10, 135, 1000, 1002]))
('I', (1002, 1002, [10, 135, 1000, 1002]))
('J', (1002, 1002, [10, 135, 1000, 1002]))
('G', (1002, 1002, [10, 135, 1000, 1002]))
('K', (1002, 1002, [10, 135, 1000, 1002]))
('L', (1002, 1002, [10, 135, 1000, 1002]))
('M', (1002, 1002, [10, 135, 1000, 1002]))
('N', (1002, 1002, [10, 135, 1000, 1002]))

I would have expected `0` all the way through.

However, if I initialise the Pool with `maxtasksperchild=1` the isolation seems as expected.

I don't know whether this is a bug or I'm foolish to invoke multiprocessing like this. I've run out of time to investigate this further. It's certainly strange behaviour to me and I thought I better report it, since reproducing seems fairly deterministic.
msg390600 - (view) Author: Bartosz Kwitniewski (zerg) Date: 2021-04-09 09:41
It works as intended - pool of 5 processes is being reused with new data:
- First, 5 processes are created as root,
- in first run of check_permission they drop their privileges to user,
- when they finish processing check_permission function, they are not killed, but provided with new path for processing, therefore they retain their lower privileges,
- when maxtasksperchild=1 is used, processes are killed after single run of check_permission and recreated with root permissions.
Date User Action Args
2022-04-11 14:59:23adminsetgithub: 83144
2022-01-16 19:59:50iritkatrielsetstatus: open -> closed
resolution: not a bug
stage: resolved
2021-04-09 09:41:43zergsetnosy: + zerg
messages: + msg390600
2019-12-04 05:34:03romanofskicreate