Alright. The consensus is that it's not worth the pain. Our solution right now, then, is to prepopulate /etc/passwd with a ton of users.
Thanks for your advice. -Dave On Sat, Aug 28, 2010 at 3:31 PM, Graham Dumpleton < [email protected]> wrote: > On 29 August 2010 08:23, Graham Dumpleton <[email protected]> > wrote: > > On 29 August 2010 02:33, Dave Paola <[email protected]> wrote: > >> 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. > > 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. > > Graham > > >> Thanks for your time, > >> Dave Paola > >> > >> On Sat, Aug 28, 2010 at 5:10 AM, Graham Dumpleton > >> <[email protected]> wrote: > >>> > >>> On Saturday, August 28, 2010, Dave Paola <[email protected]> wrote: > >>> > Hi all, > >>> > > >>> > 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? > >>> > >>> 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. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<modwsgi%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
