<quote who="John Ferlito">
> ie world readable so the webserver can open it. Hence the problem
> everyone can see the db password.
>
> I'm assuming things like php would have similar issues
I generally use a file layout like this:
~/url.com/root
/include
/otherstuff
/databasefilesmaybe
/logs
and put all of the include files out of the webserver's immediately servable
area (ie. not out in the public web tree). Each user has their include
directory prepended to their include path, so they needn't specify where,
yada. That's the external issues dealt with.
Then, I set it so that scripts running under ~/url.com/ only have access to
that tree - they cannot open files in other areas of the filesystem; errors
spew if they try (see open_basedir[1]). That's the local issues dealt with
- at least from the perspective of the scripts, and you're at the mercy of
your scripting module's security in this area.
Fixing the issue for shell users is... "Hard". :)
This is done with PHP, but I'm sure mod_perl can offer similar
functionality. Doubtless, Gus will amaze us with how it can automagically
chroot each script and suck in db authentication information from the random
clinks of coinage in Las Vegas.
- Jeff (who has had far too much exposure to the godawful mess that is PHP
in the last few weeks)
-- [EMAIL PROTECTED] ------------------------------- http://lwn.net/daily/ --
chown -R us:us yourbase
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
