[NTLUG:Discuss] su?

[Aaron Goldblatt]

> Adding the user in question to the www group doesn't work
> (already tried it), because the web server will not serve a file
> unless it is _owned_ by www.

Okay, so now I have to ask:  Why is this the case?  This sounds like a poorly 
configured web server.  What this means is that you can't have individual 
users be responsible for their own changes, as you've already seen.

My Apache will serve anything that the httpd user (nobody in my case) has 
read access to, as long as it can be served from a path the web server will 
look at (/htdocs or ~/public_html).  Why will yours not do this?  If it can't 
do this, is this a reason you might consider ... uh ... redoing things 
correctly?

Here's the idea:

Allow users to log in as, say user[1..3], in group group1.  Use the 
previously described cron job to set permissions if necessary:

-rwxrwxr-x user1.group1 file
-rwxrwxr-x user2.group1 file
-rwxrwxr-x user3.group1 file

The cronjob command would be something like chgrp -R group1 /htdocs

Typically your web server will run as www or httpd or nobody.  The above 
permissions allow for your class of users who need this access to all be in 
group1, but each to have their own username and password (no shared secrets 
to compromise, ergo added security), and the www user can read the necessary 
files, but if someone were to blow a hole in your server daemon, they would 
not have enough access to screw up your web site beyond taking down the 
daemon.  This is what you want.

I've never been able to get FrontPage extensions installed, but I honestly 
have to refuse to believe that the FP software is so poorly designed that the 
web server daemon process must own the files to serve them.  It totally 
defeats several of the purposes of running the daemon as a no-privs user, and 
if, in fact, that's the case, it's an excellent reason to never, ever use 
FrontPage extensions.  Please lie to me and tell me this isn't how it works.

ag