Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to set up per-user trac instances, using fcgid. The problem is that trac requires rw access to the trac instance, so I need the fcgi process to run under the respective user.

I have the suexec, fcgid, and userdir Apache modules installed (on Debian). I put up vhost directive

ScriptAliasMatch /~(.*)/trac /home/$1/public_html/trac.fcgi

This works insofar as trac.fcgi is run, but unfortunately, under the www-data user. How can I make fcgid launch it under the $1 user?

share|improve this question
    
What's the rest of our FastCGI related options in your configuration and where are the located? –  Reece45 Jan 17 '11 at 12:15

3 Answers 3

up vote 2 down vote accepted
+100

I'm using the IUS RPMs from Rackspace, and suexec came compiled and configured by default.

Here are the pertinent parts of my mod_fcgid config:

LoadModule fcgid_module modules/mod_fcgid.so 
AddHandler fcgid-script fcg fcgi fpl php 
DefaultInitEnv PHPRC  "/etc/"
FCGIWrapper /usr/bin/php-cgi .php

I suggest removing the "ScriptAliasMatch" Directive and using the AddHandler directive globally or in the UserDir section. Under my setup, any UserDir folder (i.e. ~/public_html) would automatically use suexec for the user in question.

share|improve this answer
    
Thanks a lot! Works exactly as I asked for. –  Martin v. Löwis Jan 18 '11 at 22:59

Trac is written in Python and supports running under mod_wsgi (per an item in the FAQ), so I'd drop several of those moving parts and switch to the fantastic mod_wsgi, which supports specifying a user for a script to run as. I use this functionality for another project and it works well.

Checking for the official mod_wsgi docs, to point you at how this is done, I see that the docs include a page on Trac integration which has many examples, including specifying particular users to run as. So your best bet is just to read:

http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac

share|improve this answer
    
I don' think this can work. IIUC, to make this work, I need to use the user= parameter to WSGIDaemonProcess, which only works when I run Apache under the root account. This I clearly don't want to - it must run under the www-data user. Furthermore, I don't want to modify the Apache configuration every time a new account is created; instead, either some wildcard mechanism could work (as in my example), or a per-user .htaccess file should be be used (which doesn't work for WSGIDaemonProcess). mod_wsgi is incapable of meeting these requirements, as it never execs. –  Martin v. Löwis Jan 12 '11 at 9:33
2  
Under a normal Apache setup, Apache always starts as root and only switches to the www-data user in child processes after they have been forked. That the Apache root process always runs as root allows the user option of mod_wsgi daemon process to work, in as much as it will switch to that user only after fork from root process as well. So, you don't need to set Apache 'User' directive to root so it runs completely as root and Apache will actually prohibit you from doing that. As to lack of dynamic daemon process creation, you are correct and it is limited in that respect. –  Graham Dumpleton Jan 12 '11 at 20:57
    
@Graham Dumpleton: I see, it's good to know. I guess the lack for dynamic creation of servers running under a different uid is actually a consequence of that feature (different UID) only working during startup. With many dozens Unix user accounts, I don't want to have that many trac processes around. So something based on userdir and/or suexec would really be useful - it doesn't have to be fcgid. –  Martin v. Löwis Jan 12 '11 at 23:14
    
No, that's not quite right. Assuming prefork MPM, there will be one process left running as root, which acts as a supervisor and does not handle requests, and then a bunch of processes running as the runtime user which handle requests. So there's nothing intrinsic preventing mod_wsgi from handling arbitrary users, it's a Simple Matter Of Programming to make it do so (sorry Graham, not trying to create work for you). I missed the implication that there would be "many", sorry. –  Phil P Jan 13 '11 at 0:33
    
Phil is correct. The only thing stopping mod_wsgi from handling dynamic creation of daemon process groups where user is also determined at run time based on some criteria, eg., owner of script file, is the author not having written the code to do it. –  Graham Dumpleton Jan 13 '11 at 2:09

With mod_fastcgi, you can use the following to enable Suexec execution of FastCGI script:

FastCgiSuexec '/usr/lib/apache2/suexec'

The path to suexec may need to be modified, this example comes from a Debian system.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.