Its true, but on a secured intranet it shouldn't be so bad
For me there's no ``shouldn't be so bad''. I only stick with something that is known as good (secure), nothing else. But that's _my_ oppinion about security (and no customer/user complained yet).
When the PHB {pointy headed boss} says he needs it done today sometimes you
gotta make that call
Of course, but that doesn't imply unsecure solutions... especially when it's something like suid where problems are known.
I didn't give this advice to force everyone to use it outright, i only wanted to mention it at all as nobody else did.
I don't like it anymore than the next guy , but when it comes to providing a solution sometimes it HAS to be done
See above. IMHO noone should implement things without knowing the possible security impacts.
If implementing suid stuff one should know why and how.
This happened in the last company and we had to use suid, but we opted for
suidperl other than that I don't really remember mush as I was coding and my
team mate was handling the installs and config for suidperl
I repeat myself if i say something further about that topic... ;-)
Remember: It's my advice so people _know_ there is a secure solution for this :-)
Kind regards, Simon
[...]Rajesh Pethe wrote:I'm new to mod_perl and am enjoying every bit of it, I have new problem, I want to execute suid scripts from mod_perl i.e. the
script called from mod_perl should be executed as a priveliged user and not as default 'apache' user.
Hi Rajesh, first of all: avoid using suid. Second advice: don't use suid. If you want to execute (particular) actions as root use sudo instead.
I'm really wondering nobody else noticed this yet as suid is evil and known for security concerns.
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
