Bostjan Skufca (at) domenca.com wrote: > is there a way to chroot execution of perl script within apache? > > Basically what I would like to achieve is like this: > There are users on the system and these users have their homedirs - as usual. > Within these homedirs they have domain directories which hold files for > assigned domains and every domain dir has it's own cgi-bin directory, eg: > > /home > /home/user01 > /home/user01/domain01.com > /home/user01/domain01.com/cgi-bin > /home/user01/domain02.com > /home/user01/domain02.com/cgi-bin > /home/user01/domain03.com > /home/user01/domain03.com/cgi-bin > /home/user02 > /home/user02/domain04.com > /home/user02/domain04.com/cgi-bin > /home/user02/domain05.com > /home/user02/domain05.com/cgi-bin > /home/user02/domain06.com > /home/user02/domain06.com/cgi-bin > /home/user02/domain07.com > /home/user02/domain07.com/cgi-bin > etc. > > Now i would like to chroot execution of cgi's for domain01, domain02 and > domain03 to /home/user01 and likewise for domain04, domain05, domain06 and > domain07 to /home/user02. > > Therefore apache's srm.conf entries should look somewhat like this (note the > CGIChroot directive): > > <VirtualHost *> > CGIChroot /home/user01 > DocumentRoot /home/user01/domain01.com > ServerName domain01.com > CustomLog logs/domain01.com.access.log combined > </VirtualHost> > > <VirtualHost *> > CGIChroot /home/user02 > DocumentRoot /home/user02/domain04.com > ServerName domain04.com > CustomLog logs/domain04.com.access.log combined > </VirtualHost> > > Now my question: is this by any means possible to achieve? Could > invocation of perl be done through some setuid root program which > would chroot to given directory first (assuming perl and neccesary > libraries are installed in every user's homedir), drop privileges > back to apache-default or whatever specified and execute the cgi > script? It's certainly possible, however: 1. I have no idea whether such a program currently exists. If not, the obvious starting point would be the suExec program, as that has similar security requirements. 2. Given the complexity involved, it would be quite easy to get it wrong, in the sense of decreasing security rather than increasing it (there are reasons why the chroot() system call requires root privilege). 3. Chroot restricts filesystem access; it doesn't restrict access to other system resources (e.g. network sockets, SysV IPC entities). 4. Setting up a chroot filesystem is far from trivial. Apart from the perl binary and its libraries, you may also need various bits of /etc, /lib and /dev. Running "strings /usr/bin/perl | fgrep /" suggests that it may need /dev/null, /dev/urandom and /dev/fd/*; the latter is usually a symlink to /proc/self/fd, which would require /proc. Doing likewise for libc shows quite a few filenames; good luck on figuring out which ones you need to run perl. 5. What benefit do you expect chroot to provide which can't be obtained far more simply with appropriate filesystem permissions? -- Glynn Clements <glynn.clements@xxxxxxxxxx> - : send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
