Problems with serverroot
David J
21 January 2010, 16:24
Hiawatha version: 6.19 (built from source using debian instructions)
Operating System: ubuntu 8.04lts
I've been testing hiawatha and all has been working great for me including php-fcgi support etc.
However, I wanted to use the additional security of setting serverroot, but I cannot get this to work reliably/properly.
From my known working config I changed the paths for log files and websiteroot and set serverroot then restart.
On restarting I get compliants to the console:
Warning: error redirecting stdin
Warning: error redirecting stdout
and in the system.log:
Warning: error redirecting stderr
The server is up, and serves plain html files from the websiteroot, but returns 404 not found errors for the php pages.
After a few minutes the server dies. I cannot find any error messages in the logs (presumably because the stderr/stdout redirects failed.)
Occasionally I get the following in the browser window when requesting a plain html file:
libgcc_s.so.1 must be installed for pthread_cancel to work
Looking at the page source in the browser, this is content of the requested page, not the above which was actually displayed, the the page has been sent, but this has been tagged on after somehow.
Any clues as to what I'm doing wrong, or is this a bug of some kind? An example config file using serverroot would be a helpful addition to the documentation!
Thanks, DJ
Hugo Leisink
21 January 2010, 16:44
I haven't used the ServerRoot setting for some time. I will take a look at it soon and get back to you. It's very well possible that some bug has sneaked it's way in.
David J
21 January 2010, 17:26
Thanks.
A bit of additional information, as I continue to investigate.
To serve static content with ServerRoot = /var/www I have to modify WebsiteRoot from /var/www/default to /default for file to serve correctly.
I have now successfully served php via php-fcgi by leaving the WebsiteRoot as /var/www/default or moving the file to /default.
In otherwords, the path being passed to php-fcgi is the path within the chroot of the server, but the php-fcgi process needs the full path (it is not running chrooted). So the fix for the 404 errors on php appears to be to chroot php-fcgi withing the same directory as the hiawatha - I'll give this a try.
Still complaining and falling over just the same though!
DJ
Hugo Leisink
21 January 2010, 19:05
Try linking with '-lgcc_s' and let me know if that solves the problem.
Hugo Leisink
21 January 2010, 20:16
I've been doing some research. It looks like pthreads and chroot aren't working together well. The ServerRoot options isn't being used by any user as far as I know. Modern security features like grsecurity and AppArmor are far better then a simple chroot. So, I'm thinking about removing the ServeRoot option for the next release. I required some tricky code, so that's another good reason to get rid of it.
David J
25 January 2010, 16:41
The reason I'm wanting to use chroot rather than AppArmor is the VPS I'm using has a xen tweeked kernel without the AppArmor module and my provider is not happy about the use of other than their supplied kernel setup - no support if I try and in breach of the terms of service if it affects other users. Not a unique situation, I'm sure.
However, I now have hiawatha working happily in a chroot environment using ServerRoot. The follow mods/fixes are needed:
1) To fix the warnings about redirecting stdin/stdout/stderr - either mod hiawatha.c to move the block of code where the redirects to /dev/null are made to a position just before the call to chroot(), instead of just after and rebuild. Alternatively, create /dev/null device within the chroot directory. A similar mod is also needed in php-fcgi.c for the same reason.
2) To fix the crashes of hiawatha, and the odd error message about libgcc_s - as you suggested, needs -lgcc_s adding the the libraries linked. Did this by adding -lgcc_s to the hiawatha_LDADD line in Makefile.am followed by configure and make. This throws a warning about no symbols from the library being used, plainly this is not the case. Alternatively, libgcc_s.so.1 (on my setup - may vary) can be copied into /lib in the chroot directory. It appears this library is bound late, after the call to chroot().
With these changes I now have hiawatha running with php5 under fastcgi and SSL and it appears stable. The php5 setup needed a bit of work to get everything needed into the chroot directory, but this is always the case setting up chrooted apps. A howto on setting up lighttpd + php5 in a chroot helped a lot.
Hope this helps. David J
This topic has been closed.