suid & mod_perl
2009-05-11 21:32:09.771819+00 by Dan Lyke 7 comments
By the way, the SUID bit has no effect when set apps that you think are CGI but are actualy executing via mod_perl.
2009-05-11 21:32:09.771819+00 by Dan Lyke 7 comments
By the way, the SUID bit has no effect when set apps that you think are CGI but are actualy executing via mod_perl.
[ related topics: Web development Perl Open Source ]
comments in ascending chronological order (reverse):
#Comment Re: made: 2009-05-11 22:06:02.881081+00 by: meuon
Good. :)
The best way I know to make things on a webapp server run as root, is to talk to them via SQL. ie: Your "doasroot" deamon runs as root, connecting to SQL and processes the functions (not actual commands) that it understands as it's role.
#Comment Re: made: 2009-05-11 23:04:24.387621+00 by: spc476
And here I thought that modern Unix systems never honored the SUID bit on scripts, only executables ...
#Comment Re: made: 2009-05-11 23:12:27.975145+00 by: meuon
On a real *nix system, there is little difference. Especially if you do weird things like start the script with:
#!/usr/bin/suidperl
#Comment Re: made: 2009-05-12 00:23:45.131522+00 by: Dan Lyke
Heresy! One who'd call a Perl application a mere "script"...
Perl has an option to have an executable that can do privilege escalation, and then has all sorts of hoops that you have to jump through to prove that you're worthy of said escalation...
Otherwise, of course, I'd just write a C thingie that did something similar, and I prefer that the Perl community has thought through a lot of the gotchas.
Meuon, the conclusion I've come to is that I need a similar option for my database, so access will be, for starters, via suid Perl scripts, probably with a socket connection option to follow.
#Comment Re: made: 2009-05-12 08:08:15.304686+00 by: spc476
Ah, see, I don't actually *program* in Perl, as I really don't like it (I like PHP even less), so I didn't know about the suidperl program.
#Comment Re: made: 2009-05-12 16:48:31.095142+00 by: other_todd
I'm a Perl programmer and I have no problem with calling them scripts!
But I can't help with the whole privilege escalation thing because that is an area of Perl I have never gone near with an Eleven-Foot Pole (tm). My philosophy on Perl scripting is that, if the script is going to do something, then the user whom the script runs as should be given rights to do that thing. On our servers here, that means that we have a special user whom Apache runs as - which means that in a CGI environment the Perl also runs as that user - and has the rights to do all kinds of interesting things. If a script calls for something that falls beyond those permissions, it's usually a clue that we need to reexamine why we need that script to begin with.
(And if my script needs to do something that can only be done by root, then it usually means I'm doing something wrong, or that the permissions structure on that machine is badly messed up.)
#Comment Re: made: 2009-05-12 17:03:37.171821+00 by: Dan Lyke
Todd, in this case it's that I want several UIDs to be able to do something (it's the usual "user on the machine, www-data, and remote users sshing in" problem), so I've got this SUID app that duns its arguments and inputs, and then switches its identity to the UID that actually owns the file store and does the manipulation.
Which is just one step removed from Meuon's "listen on a socket and do stuff" approach.