gunicorn/util.py set_owner_process Mangling gid on RHEL8 + Google Cloud Platform (very large int group id)

[jbisbee]

I'm using Python 3.9.18 on Red Hat Enterprise Linux 8. My uid and gid values are crazy high under RHEL8 and Google Cloud Platform. As a result, they are hitting a hard coded condition within gunicorn/util.py

151 # versions of python < 2.6.2 don't manage unsigned int for
152 # groups like on osx or fedora
153 gid = abs(gid) & 0x7FFFFFFF

Where my gid is being changed from 4133075255 to 1985591607 and then because they don't match, gid is attempted to be set and gunicorn dies because I'm not a priveledged user and I don't have permission to set gid (which is only firing off because my gid was unjustly molested 👎)

[pajod]

Fairly certain that was a spot-fix for a bug that no longer appears on any supported system/version.
.. and Gunicorn should not only drop that line, but also stop messing with uid/gid/groups altogether when there is no need to.

[benoitc]

top messing with uid/gid/groups altogether when there is no need to.

@pajod care to elaborate? We need to be abble to set user and group to detach worker process and handle permissions approriately. Unsure what you mean there

[pajod]

stop messing with uid/gid/groups altogether when there is no need to.

@pajod care to elaborate?

This bug (and the WSL2 chown problem) should simply not affect those already running Gunicorn unprivileged. If Gunicorn was not provided with a setting for uid/gid changes, it should also never fail in setgid/setgid/setgroups/chown/initgroups calls.

• Gunicorn currently defaults to: change it, possibly to the same thing it already was (User.default = os.geteuid())
• I suggest Gunicorn should default to: make no attempt at modifying uid/gid unless told so (User.default = None)

[nicholas-johnson-techxcel]

Running this with Langflow is a nightmare. It should not be trying to change gid but it does, seemingly constantly, and it does not give up nor work properly.

[benoitc]

the question is rather, why the user you launch can't assign its own gid. I don't reproduce suc issue in any env I use. if gid is mismatching then we should handle the case wit h oses not capable to follow a spec. Not removing a feature.