Joshua Rodman wrote:
> 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.
That would be wonderful. We are writing the documentation using a
Wiki. For course, you are more than welcome to add all those
clarifications:
http://www.0x50.org/wiki/
> 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 understood there were issues rather than documentation problems. I
guess it was my mistake. ;)
Currently the documentation isn't very good. It was been mostly
written by non-English speakers (which means it is full of grammar
mistakes), it lacks some points, etc.. so, any kind of help on this
is really precious for the project.
>>>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.
Okay, so it is a feature request, isn't it? ;)
What about something like..
======
UserDir "$HOME/public_html" {
# ..
}
======
or
======
UserDir "/users/$USER/" {
# ..
}
======
I guess it should be enough if you add two variables:
- $USER: to be replaced by the user name
- $HOME: Idem, but using the home information from getpwent()
>>>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.
Well, IMHO we don't need to pick up one of those methods. For
example, the method I have proposed previously seems to be much more
flexible than the thttpd or the Apache one.
> 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
>
--
Greetings, alo.
http://www.alobbs.com
_______________________________________________
Cherokee mailing list
Cherokee@lists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
