I've created the chroot jail for apache, and modified the startup script to run apache as a chrooted daemon, but I get an error: 18077 chdir("/home/httpd/chroot") = 0 18077 chroot("/home/httpd/chroot") = 0 18077 execve("/usr/sbin/apache", ["/usr/sbin/apache", "-D", "SSL", "-D", "PHP4"], [/* 39 vars */]) = -1 EACCES (Permission denied) (note that /home/httpd/chroot is on /home, and /home is mounted exec.) running the binary directly, I don't get an error: 1567 execve("./apache", ["./apache"], [/* 40 vars */]) = 0 1567 uname({sys="Linux", node="fedora", ...}) = 0 Here is the line I changed in /etc/init.d/apache: start() { ebegin "Starting apache" start-stop-daemon -o --quiet --start --startas /usr/sbin/apache \ -r /home/httpd/chroot \ --pidfile /var/log/apache/pid -- ${APACHE_OPTS} eend $? #--pidfile /var/run/apache.pid -- ${APACHE_OPTS} and the directory structure: # ls dev etc home lib usr var bash-2.05b# ls dev etc lib usr/sbin/ usr/lib dev: null etc: apache group nsswitch.conf passwd php4 resolv.conf lib: ld-linux.so.2 libcrypt.so.1 libm.so.6 libpthread.so.0 libc.so.6 libdl.so.2 libnsl.so.1 libresolv.so.2 usr/lib: apache libcrypt.so.1 libjpeg.so.62 libmysqlclient.so.10 libttf.so.2 apache-extramodules libcrypto.so.0.9.6 libltdl.so.3 libpdf.so.1 libxml2.so.2 libX11.so.6 libdb-3.2.so libmcrypt.so.4 libpng.so.3 libz.so.1 libXpm.so.4 libexpat.so.0 libmhash.so.2 libssl.so.0.9.6 libbz2.so.1.0 libgdbm.so.2 libmm.so.12 libt1.so.1 usr/sbin/: apache Note that I'm using mount -o bind for the actual apache stuff (this is what I usually do on solaris, except its mount -F lofs -o blahblah): /etc/apache on /home/httpd/chroot/etc/apache type none (ro,bind) /etc/php4 on /home/httpd/chroot/etc/php4 type none (ro,bind) /home/httpd/htdocs on /home/httpd/chroot/home/httpd/htdocs type none (ro,bind) /usr/lib/apache-extramodules on /home/httpd/chroot/usr/lib/apache-extramodules type none (ro,bind) /usr/lib/apache on /home/httpd/chroot/usr/lib/apache type none (ro,bind) /var/cache/apache-mm on /home/httpd/chroot/var/cache/apache-mm type none (rw,bind) /var/log/apache on /home/httpd/chroot/var/log/apache type none (rw,bind) /var/log/php4 on /home/httpd/chroot/var/log/php4 type none (rw,bind) I intially thought it might be grsec, and filed a bug, and it was ignored, mostly, I think because I was suggesting a feature add at the same time. This time, I tried using the -r option w/o grsec (ie: grsec isn't in this kernel) and it still doesn't work. I'm under the impression that something is broken about how the -r optoin works wrt execve, but I don't know what. I've also tried it with chroot /home/httpd/chroot /usr/sbin/apache -f /etc/apache/conf/apache.conf, with the same EACCESS return value.
Could be because apache tries to run php which is not in the chroot ....
I'm using mod_php --- I was under the impression I wouldn't need php b/c of that. Besides --- I should get a different error (or so I would think) since php isn't there. Heck, I don't even have php installed on this machine --- and so I would think I'd get the same kind of error (or at least an error of some kind) running apache alone.
Ok, I just saw the PHP in there. Anyhow, if it also do this with 'chroot...', then Im guessing its not a start-stop-daemon problem, but rather with chroot/apache/config ?
Okay, I'm dumb --- the libraries weren't executable, and apparently they have to be inside a chroot. I've fixed that; it works now. Would an ebuild for apache inside a chroot be of any use? or is that not really too helpful?
this is ridiculous. this is bugs.gentoo.org not i-need-technical-support.gentoo.org
> I intially thought it might be grsec, and filed a bug, and it was ignored, > mostly, I think because I was suggesting a feature add at the same time. Ummmmmmmmmm, NO. I told you to debug your problem yourself. You want to customise and hack your system up into pieces in order to make it the way you want? Fine. I do that too. But I dont then turn around and expect everybody else to fix my mistakes for me. You on the other hand, have now submitted this garbage TWICE. I think its safe for you to assume that anything else you submit to this "bug tracker system" is going to be pretty much ignored by me. Have a nice day.
What led me to believe my request had been misunderstood was that I filed it as a feature add, and I received this back (this is bug 19724): > umm, this is bugs.gentoo.org, not free-technical-support.gentoo.org > > the apache ebuild doesnt support chroot'ing the daemon on its own. > if you want to do that, then set it up yuorself. and debug it > yourself. So I tried, and failed. I worked on it some more, and still couldn't figure out what was wrong, asked other linux users I knew, and finally came here to state that as far as I could tell it was a bug. I'm sorry if I've wasted your time, but I was trying to get something to work, thought I'd found a bug, and had hoped it would be helpful to track it down, since I didn't know anyone else running Apache inside a chroot on linux. Again, sorry Donny. Where should I go in the future to ensure that I track down all possible options before submitting a bug report?
