Joshua Rodman wrote:
>> 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?
It will read all the active virtual hosts information, and then,
when all the configuration is parsed, it will jail itself.
> 2) Will Cherokee open the logging files before chrooting, or after?
Before. You can localize your log files outside the chroot
environment is you want.
> 3) Will Cherokee in any cases need to dlopen() any files after
> chrooting?
No. It will load all the needed plug-ins before the chroot call.
> 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?
It uses getpwent(), so it needs the faked file. I'm not quite sure
if keep a cached copy of the system /etc/passwd is something useful.
What is the point of that? When you Chroot your server is because
you want to isolate it from the system environment.
>> 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.
Oopss.. you are right, sorry, my mistake.
It should be:
========
Chroot /var
DocumentRoot /www
Directory /icons {
Handler file
DocumentRoot /www/images/icons/
}
========
The reason is simple. The server reads the configuration and stores
the paths internally. Then, it chroot itself, and finally it starts
to attend requests. The server is meant to be in the root
directory, either it is inside or outside the chroot.
> The following configuration is working as expected:
> /etc/cherokee/cherokee.conf:
> Chroot /opt/kmods
>
> /etc/cherokee/sites-available/default
> DocumentRoot /
> Directory / {
> Handler common
> }
Yeah, it is the expected behaviour. Well, at least it is the
current behaviour.. which seems fair enough to me. Is there
something you would change?
It may be a good idea to parse the paths in the configuration path
when Chroot is active. I mean, to write the previous example like
this:
========
Chroot /var
DocumentRoot /var/www
Directory /icons {
Handler file
DocumentRoot /var/www/images/icons/
}
========
So, it should remove the "/var" from every single path in the rest
of the configuration. It looks like a good idea to me, at least it
is more comprehensible.
>>> 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.
Besides the couple of bugs you have found, that is the expected
behaviour.
> 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.
Well, that kind of sucky things is what we are trying to improve in
Cherokee. :-)
That sort of fixed paths are not the best option in my opinion. If
we really want to support user directories lets do it in the best
way for almost all of web server users: we can skip the most strange
cases, but we have to support the common one in the most flexible
way.
Do you have some idea to improve the user directory support? :-?
> This means the httpd is simpler, and chroot behavior is simpler to
> understand. You may have other priorities.
Indeed. Cherokee aims to cover the most common cases in a flexible
way. Simplicity is something good, but I think it doesn't worth to
lose basic functionality in order to gain simplicity.
--
Greetings, alo.
http://www.alobbs.com
_______________________________________________
Cherokee mailing list
Cherokee@lists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
