Permit the use of UIDs

[GoogleCodeExporter]

This is an enhancement request.

We need that wsgi runs with UID that doesn't exists in /etc/passwd, and we 
can't user ldap or anything else that can be used as uid.
We run a massive hosting plateform that use virtual UIDs, atm we use 
apache-mpm-itk to run PHP apps with those virtual users, if we want to permit 
users to run python apps, we need to be able to run thoses apps with virtual 
users.

I think it should be a little patch, that can be only a directive in 
configuration file or anything else.

Original issue reported on code.google.com by nahuel.a...@openedition.org on 22 Jan 2013 at 10:38

[GoogleCodeExporter]

My recollection in this was that this was only a problem in relation to looking 
up the home directory. Set the home option to WSGIDaemonProcess to a directory 
explicitly, and it shouldn't consult /etc/passwd.

If this is not the case, please provide the actual errors you are getting.

Original comment by Graham.Dumpleton@gmail.com on 23 Jan 2013 at 12:52

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I have the same problem, as far as I understood it it's not just the home 
directory.

If I specified a user by his uid ( for example, #2001), the error is : 
"Couldn't determine user name from uid."

It's because (entry = getpwuid(uid)) return NULL (line 9810 of mod_wsgi.c 3.4)

There is a discution abvout it here : 
http://groups.google.com/group/modwsgi/browse_frm/thread/193c15873ccba18c

But, I think that if modwsgi can work with just an UID, it should be usefull to 
allow it. Maybe a particular syntax :
user=foo    <- by username
user=#2001  <- by UID, with check
user=%2001  <- by UID, check disabled

Best regards,
Alan

Original comment by fufr...@gmail.com on 23 Jan 2013 at 1:21

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This kind of syntax should be great.
Could it be planned in a next release?

Original comment by nahuel.a...@openedition.org on 1 Feb 2013 at 12:47

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This turns out to not be quite that simple as there are various places in 
mod_wsgi that rely on being able to look up a valid password database entry for 
the uid used. There are also places in Python itself during startup that rely 
on being able to do so.

To allow this somehow would require at least the following changes.

When processing WSGIDaemonProcess if user option is of form #nnn, then if #nnn 
cannot be mapped to a password database entry to get actual user name, use #nnn 
instead for time being.

When creating daemon process, would by default change the working directory to 
home directory of the account. This would need to recognise this case and leave 
home directory as is or make it /.

When creating daemon process, call to initgroups() isn't going to work if given 
#nnn as user name.

When initialising each interpreter context, would need to work out what should 
be done as far as overriding HOME, USER, USERNAME and LOGNAME with a sensible 
value or whether leave as what may have already existed, which can in some 
cases cause problems,

When the Python interpreter itself starts up and it tries to determine 
PYTHONUSERBASE for a user it will fail as it tries to look up password database 
for home directory. This cause an exception during processing of site.py which 
potentially leaves interpreter in incompletely initialised state.

One possibility is that if use #nnn form and doesn't map to user, that assume 
that everything as if was default Apache user, with exception that uid will be 
switched for process.

Original comment by Graham.Dumpleton@gmail.com on 2 May 2014 at 1:09

• Added labels: ****
• Removed labels: ****