Okay, this is getting frustrating. We keep missing.
This series of questions was designed to illustrate what was not clear
to me as a user who is considering using the Chroot feature. These are
the things I would like to see in documentation and which I had planned
to document, if you felt that would be useful, and if you could let me
know what the upstream form of documentation is that you use in your
project.
You have interpreted my list of things to be documented as a support
request. Obviously I already have it working, so I have figured out
these issues. I suppose I am being smallminded by being bothered by
this interpretation, but you are definitely spending unnecessary time
responding to my issues as support requests, when they are meant as
discussions of how to improve Cherokee in documentation or code.
> > 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?
> 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.
Surely you can see that the chroot() call is a security consideration,
and the ability to support user-specific content directories is a
service consideration, and that these two things are not in conflict!
To wit, I have users on my machine and i provide them with
user-spcific directories inside the chroot environment which are set up
via standard unix permissions so that they can manage the content of
these directories.
> >> 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:
> > Unfortunately, I believe this is incorrect.
>
> Oopss.. you are right, sorry, my mistake.
> It should be:
[..]
> 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.
Yes, yes, I have written code that uses an explicit chroot before.
The behavior is both simple and desirable. The first google document
for 'chroot' and 'cherokee' is incorrect and misleading. This can be
resolved by adding some documentation for Chroot which is correct.
> 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.
Personally I think this is moderately confusing in the sense that I will
wonder what happens in the pathological case of symlinks and so on. For
users who understand chroot the current behavior is very
straightforward. This might be better for those who do not, but be
careful you do not introduce problems. In any event, either way is
satisfactory of course, if there is documentation which says what to do.
> > 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. :-)
I find it frustrating that you provide no rationale for the superiority
of the apache method for user directories. The clear problem is that a
more secure (chrooted) environment clashes with the the apache method
of supplying user directories.
The symlink setup provides no problems for users of a modern shell such
as bash.
The a tranform of ~foo to /something/foo provides significant
flexibility in that it is not necessary to provide system accounts to
provide user web directories, in that it does not conflict with chroot,
and in that one can provide arbitrary permission schemes through the
simple expediency of normal unix permissions.
Contrarily, an apache-style setup _must_ have traversal access to every
user's home directory, most not be chrooted away from the user home
directories, and must rely on the extra complexity of additional
interfaces.
Certainly I can understand prioritizing apache-style setup for some
reason, such as "familiar to apache users", but to cast aspersions on
one solution versus another without any rationale seems foolish.
You should think about whether your current approach gains you any
flexibility that you will actually use.
-josh
_______________________________________________
Cherokee mailing list
Cherokee@lists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
