Thanks for the comments. My post wasn't as clear as it should have
been. I was trying avoid irrelevant details (but failed). The more
complete story is that I've taken over for a consultant that built a
perl based website. All users supply a username and password.
There's a page that allows users to edit their vacation message and
toggle their away/back status. That part is broken because of the
permissions issue. Currently the code attempts to set the away
message by:
system "/usr/bin/vacation -i";
system "cp -p /home/$remoteuser/vacation.forward /home/$remoteuser/
\.forward";
To get something perl-specific into that thread: Don't construct command
lines from untrusted user input. Even if you are sure that $remoteuser
can only be an existing user name that cannot contain any funny
characters (like " ", "/" or "."), get into the habit of using the list
form of system:
system "/usr/bin/vacation", "-i";
system "cp", "-p", "/home/$remoteuser/vacation.forward", "/home/$remoteuser/.forward";
(what was the \ for, BTW?)
or to turn off the vacation message:
system "/usr/bin/vacation -i";
system "rm /home/$remoteuser/\.forward";
I haven't done web development before and made the assumption that I'd
have many more cases where 'nobody' wouldn't be sufficient.
First, don't run your webserver as "nobody". Create a specific user and
run it as that user. You may think that it doesn't make any difference
whether the server runs as "nobody" or as "foo". But if your webserver
runs as "nobody" out of the box, chances are that there is some other
stuff on the box also running as nobody, and you don't want to open a
path to privileged commands to that other stuff.
If this web server is tightly controlled and only used for controlling
user accounts, you can now give the user "foo" permission to remove
..forward files, for example using sudo. But don't just give it
permission to run "rm". Instead create a script "vacation-off", and give
it permission to run that script. So even if your server is cracked,
the attacker cannot delete any file. He can only turn off (and on)
vacation messages. (And I don't know if that is possible with sudo, but
you should strongly consider restricting these commands to run as some
"real" user, but not as root).
If your web server is also used for other stuff which is less security
sensitive (and where the web authors are probably less careful), it's a
good idea to put in another layer. Create yet another user and run only
those scripts which need special privileges as that user. You can do
this for example with suexec (with apache) or fastcgi (just about any
webserver). FastCGI is especially nice because it communicates with the
webserver over a socket - the script can run even run on a different
host than the webserver.
hp