Perrin Harkins wrote:

On Mon, 2004-05-03 at 17:24, JupiterHost.Net wrote:

So if I did it the .mpl way then /usr/foo/bar.mpl and /usr/foo/baz.mpl will run as nobody (IE untrusted user with less privileges)


If that's who your server runs as, then yes.  The "nobody" user has the
same privileges as any other user the systems I'm familiar with.  That
user typically has no login, but may have permission to write to certain
directories, etc.

cool, gotcha

(Regular .pl scripts currently run under suexec which I know mod_perl can't do since you can't split up a single process like that, will that hiinder mod_perl from running?)


I'm not sure what you're asking.  If you add something to your conf to
make all of your .pl scripts run through mod_perl, they won't run
through suexec anymore.  You would have to keep them as CGI for that to
work.  If you set it up to run some directories through CGI and some
through mod_perl, that will work fine.

That's it exactly :)
If .pl run as regular scripts under suexec they'll be run as 'foo' instead of 'nobody' but any mod_perl scripts will be run as 'nobody'
but neither will break the other...



Which is just as [in]secure as /home/foo/bar.pl , /home/foo/stuff/baz.sh, /home/foo/public_html/luz.py, correct?


Running them under mod_perl is less secure in the sense that anyone can
write a script that messes around with globals, redefines core perl
fuctions, etc. and messes up other people's scripts, since they are all
running in the same interpreter.  You really should not run untrusted
code under mod_perl without isolating it to its own apache server.

I see, perhaps I need to look into setting it up to run theri own mod_perl apache so they can shoot them self in the foot instead of others :)


(Maybe more secure since 'nobody' has less privs than 'foo', correct?)


Again, "nobody" is just another user.

- Perrin

Thanks for the great info!

--
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



Reply via email to