On Sat, Jan 07, 2006 at 10:45:22AM +0100, Alvaro Lopez Ortega wrote:
> [EMAIL PROTECTED] wrote:
>
> > The largest problem I encountered when setting up Cherokee was
> > interpreting the meaning of the Chroot option. When the chroot
> > happens and how the variables are treated/handled in accordance with
> > the chroot are the primay questions. Just the first would have
> > saved me from stracing the program a fair amount.
> >
> > Exacerbating this is that a google search for cherkoee and chroot
> > turns up this email:
> > http://alobbs.com/pipermail/cherokee/2005-May/000722.html which
> > suggests quite explicitly that the DocumentRoot should be redundant
> > with the Chroot path, which i would not have expect and in fact is
> > not correct (according to my experiences).
> >
> > I could possibly write a lousy (uncertain to be correct) first take
> > on the chroot behavior based on my experiences and source readings.
> > If this is useful, should I just edit the html, or is there a more
> > upstream documentation form?
>
> It would be useful to know how your case is, what Cherokee needs to
> implement or change, what are the functionality you are missing,
> etc.
I do not think anything needs to change, or that any functionality was
missing, but I had the following questions in my mind:
1) Will Cherokee use the site-available information from /etc/cherokeee,
or will I need to reproduce this virtual hosting information in some
form inside the chroot?
2) Will Cherokee open the logging files before chrooting, or after?
3) Will Cherokee in any cases need to dlopen() any files after
chrooting?
4) Will Cherokee identify users from the system with getpwent, requiring
a fake /etc/passwd, or will it in any fashion read and cache user
directories from outside the chroot?
Some of these questions may involve some foolishness on my part, but
they were all uncertainties.
> The Chroot option will jail the server under that path, so after the
> start up it will need all the paths to be relative to path point.
> For example, lets imagine this configuration *without* Chroot:
>
> ========
> DocumentRoot /var/www
>
> Directory /icons {
> Handler file
> DocumentRoot /var/www/images/icons/
> }
> ========
>
> For a Chroot environment, it should be written as follows:
>
> ========
> DocumentRoot /var/www
> Chroot /var
>
> Directory /icons {
> Handler file
> DocumentRoot /www/images/icons/
> }
> ========
Unfortunately, I believe this is incorrect.
After reading the email (which agrees with you) which I reference via
URL, I thought that the DocumentRoot would be interpreted irrespective
of the Chroot, but when I tried this, it did not work.
/etc/cherokee/cherokee.conf:
Chroot /opt/kmods
/etc/cherokee/sites-available/default
DocumentRoot /opt/kmods
Directory / {
Handler common
}
Accessing http://localhost/ produces the error:
404 Not Found
The requested URL / was not found on this server.
Further, an strace shows:
chroot("/opt/kmods") = 0
[...]
[pid 13678] stat64("/opt/kmods//", 0x8069ac8) = -1 ENOENT (No such file or
directory)
[pid 13678] stat64("/opt/kmods/", 0xb74501ec) = -1 ENOENT (No such file or
directory)
Thus, this configuration will cause cherokee to access
/opt/kmods/opt/kmods. I believe your example will cause cherokee to
access /var/var/www, but I have not tested it.
The following configuration is working as expected:
/etc/cherokee/cherokee.conf:
Chroot /opt/kmods
/etc/cherokee/sites-available/default
DocumentRoot /
Directory / {
Handler common
}
I am using the Debian Linux package from testing, version 0.4.29-3
> > Secondarily, I enabled the UserDir feature for my users, and had some
> > trouble figuring out how this would work inside a chroot. thttpd simply
> > transforms /~foo into /users/foo if /users/foo exists, which seems safe
> > and sane.
>
> Okay, so what you suggest is to add a check to ensure the user home
> directory exists, isn't it? (It makes quite sense for me)
Hmm, I am not sure if a check is the right idea. Maybe it is, but I
think it is okay to simply return a 404 if the file access fails.
I just like that thttpd does not care about making libc calls for
getpwent, etc. Instead it says: user html directories are inside the
chroot in '/users/username'. If you want 'public_html' or similar, use
a symlink.
This means the httpd is simpler, and chroot behavior is simpler to
understand. You may have other priorities.
I will file the issues I mentioned in the last email. But first, I will
go to sleep.
Thanks!
-josh
_______________________________________________
Cherokee mailing list
Cherokee@lists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
