running wsgi app under dynamically allocated UIDs
Dave Paola
I have a system where users upload wsgi applications and we serve them
using apache/mod_wsgi. For scaling reasons, we're simply using the
WSGIDaemonProcess directive and setting them to dynamically allocated
UID/GIDs. The problem is, we don't have associated users with these
UIDs.
Is there a way to keep mod_wsgi from trying to determine the "user"
associated with a particular UID? I can't find a directive anywhere
that does this.
Any ideas?
Cheers,
Dave Paola
www.djangy.com
Graham Dumpleton
Is there any reason why you can't have an entry in /etc/passwd for
that uid mapping to a dummy name, eg uXYZ, where XYX is the uid. You
don't need to create an actual home directory or anything else, just
have the passwd file entry be a no login account and a dummy home
directory that doesn't exist either.
As to you question, there might if changes are made to mod_wsgi code,
but don't have code in front of me right now. More importantly I want
to understand why you can't have that passwd file entry, as would be
worried that various code will break in a Python application anyway if
it doesn't exist, which would make any change pointless.
Graham
> Cheers,
> Dave Paola
> www.djangy.com
>
> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>
Dave Paola
Graham Dumpleton
> Thanks for your response. I took a look at the code and it appears I might
> be able to remove the conditional (line 9700). This would most certainly be
> a hack, as I'm completely unfamiliar with the rest of mod_wsgi.
> As to your other question: I'm the founder of Djangy.com, and as part of our
> security mechanism, we run users applications on UIDs above a certain number
> and privileged code under that number. There's no reason we can't generate
> an entry in /etc/passwd other than simplicity. There are concerns with
> scaling, e.g. if we run a user's application on more than one machine, all
> the machines must have synchronized /etc/passwd files, etc. It's just
> simpler if we avoid touching unnecessary system files.
Have you considered using LDAP as a centralised repository for
managing users and groups on your systems.
In either case, do be aware of:
http://code.google.com/p/modwsgi/issues/detail?id=200
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523743
So, you have to be careful with doing user management, ie., deleting
users, when mod_wsgi is configured to use that user.
> That said, if there's no other solution, then we'll probably go ahead and do
> that. Is there any reason the rest of mod_wsgi needs to have the 'user'
> property of that "entry" struct?
The user name is also required when setting up the group for the
process. You may be able to get around that by using the
'supplementary-groups' option in mod_wsgi 4.0 as that allows you to do
a degree manually set group membership rather than rely on
/etc/groups.
Graham
Graham Dumpleton
You would also need to use 'home' option to override home directory so
Apache logs don't fill with warning messages about not being able to
work it out.
The killer though is that mod_wsgi will still likely crash, as for
daemon processes it will override HOME environment variable and to do
that it needs a passwd entry for account and the code doesn't cope
with there not being one. The code could perhaps be changed to make it
more resilient, but this is the sort of problem you will have with any
third party packages or parts of Python standard library. If any code
always assumes it is running as a uid which has a matching passwd
entry and there isn't one when it tries to use it, then it will likely
crash.