Mathieu CARBONNEAUX
2008-05-07 22:15:15 UTC
This is the last version of my mod_chroot hack! if anyone are interest
on it...and testing it...
* i've remove all unecessarie code (no check ulimit for coredumpdir!
i've removed commented code...).
* fixchroot is of by default (no request modification at runtime by
default).
* i've corrected a probleme with ap_server_root_relative in adding
ap_server_root in fixroot code.
* i've remove pre_config hook, and move the reste in pre_mpm hook.
i've tested it on ap 2.0.49/59 and 2.2.4 on linux 2.6 (SLES10/OpenSuse
10.3 and Centos 5.1).
yes i've seen the discution apache dev list about integration of chroot
in ap 2.x... they use the same logic i've used (making the chroot in
child intialisation vs in pre_config) but they do it in the
unix_setupchild and not in adding generic hook juste before
unix_setupchild...
Regards,
Mathieu
------------------------------------------------------------------------
*From:* Marek Gutkowski
*Sent:* Thu, 21 Feb 2008 23:46:30 +0100
(ChrootFixRoot no) to work like the current version but with the
advantage of the chrooting in child_init (this not require the path
translation) phase (pid file, lockfile, scoreboard file are made
outside the chroot and the apache reload work!).
Also it possible to rename ChrootFixRoot with
ChrootPathTranslation...
If it's deactivated no work are done in request processing...
But with the constraint of the documentroot directory existance check
that are done before chroot (problem already existing in current
version, is one of the problem that the path translation adresse)...
I understand that. I just don't really like the solution :)
chrootdir if you set directly the path in chrootdir!! (if you not use
the vars:DOCUMENT_ROOT with chrootdir)
and you can use documentroot in virtualhost, it's work fine also (all
are translated with the current document_root, and it's reseted by
apache at each request...)...chrootdir use only the globale
documentroot if you use vars:document__root...
But you still can't have different ChrootDirs for different virtual
hosts... So basically your "var:..." expression is evaluated only once.
I believe it's better to enter the path directly and have less code.
application) receve the real path in the chroot. is a problem ? the
developper need only to take care of absolute path set in her code
(like path stored in configuration file), all path are send to
php/perl by apache are real path inside the jail! And can be directly
used by the code...
Apache does not really send paths to scripts. It passes the script path
to the interpreter, but if the script needs to use an absolute path, it
needs to take the jail into account.
CGI...
Please, please, understand that more code doesn't mean better code. It
usually means *worse* code. It means more bug possibilities. We could
add thousands of features to mod_chroot, but we don't, because they fit
better elsewhere...
coredumpdirectory with core ulimit set to 0 (the default case of
suse!)... apache say nothing in this case... and no dump done wihtout
information of apache why...
With this check apache stop at starting with error if you use
coredumpdirectory (if you set this directive is why you need to dump!
And you need to have max dump size >0!) with dump size to 0...
I read your code and I understand why you wrote those checks. I just
happen to think it's not our business. I mean - Apache doesn't check it
for itself, why should WE put this check to mod_chroot, which IS NOT
meant to have anything to do with coredumps?!?
:)
We could also check if all files in DocumentRoot are readable, if the
partition holding coredumps has enough space to store coredumps, if the
directory is writable, etc, etc, etc. But it's not our business.
before unixd_setup_child... It's the way i would like to suggest to
add in ap 2.x dev trunk in the apache dev list.
That would be a nice and clean solution. And it's backwards
compatible... But it would only make sense for Apache 2.0/2.2, see
below.
We can leave things as they are now, and refrain from messing with
Apache's internal variables.
Good news for all of us: next version of Apache (2.4) will support
chroot()ing out of the box!
regards,
--
Marek Gutkowski
on it...and testing it...
* i've remove all unecessarie code (no check ulimit for coredumpdir!
i've removed commented code...).
* fixchroot is of by default (no request modification at runtime by
default).
* i've corrected a probleme with ap_server_root_relative in adding
ap_server_root in fixroot code.
* i've remove pre_config hook, and move the reste in pre_mpm hook.
i've tested it on ap 2.0.49/59 and 2.2.4 on linux 2.6 (SLES10/OpenSuse
10.3 and Centos 5.1).
yes i've seen the discution apache dev list about integration of chroot
in ap 2.x... they use the same logic i've used (making the chroot in
child intialisation vs in pre_config) but they do it in the
unix_setupchild and not in adding generic hook juste before
unix_setupchild...
Regards,
Mathieu
------------------------------------------------------------------------
*From:* Marek Gutkowski
*Sent:* Thu, 21 Feb 2008 23:46:30 +0100
1. It makes mod_chroot much more complicated and error-prone. It
also changes mod_chroot behavior: it's now directly involved in
request processing, creating big additional risk.
[Mathieu CARBONNEAUX] You can can desactivate the path translationalso changes mod_chroot behavior: it's now directly involved in
request processing, creating big additional risk.
(ChrootFixRoot no) to work like the current version but with the
advantage of the chrooting in child_init (this not require the path
translation) phase (pid file, lockfile, scoreboard file are made
outside the chroot and the apache reload work!).
Also it possible to rename ChrootFixRoot with
ChrootPathTranslation...
If it's deactivated no work are done in request processing...
But with the constraint of the documentroot directory existance check
that are done before chroot (problem already existing in current
version, is one of the problem that the path translation adresse)...
It also breaks Apache's behavior people are used to: suddenly order
of configuration directives matters (DocumentRoot before
ChrootDir...).
[Mathieu CARBONNEAUX] you dont need to set documentroot beforeof configuration directives matters (DocumentRoot before
ChrootDir...).
chrootdir if you set directly the path in chrootdir!! (if you not use
the vars:DOCUMENT_ROOT with chrootdir)
and you can use documentroot in virtualhost, it's work fine also (all
are translated with the current document_root, and it's reseted by
apache at each request...)...chrootdir use only the globale
documentroot if you use vars:document__root...
hosts... So basically your "var:..." expression is evaluated only once.
I believe it's better to enter the path directly and have less code.
2. It doesn't actually make things much easier: while altering
virtual-to-physical mapping hides the fact we're chrooted, it
doesn't help PHP/Perl/CGI scripts. Users can get confused; I prefer
to have the user thoroughly understand what's going on BEFORE
things start to work, not at some random moment in the future.
[Mathieu CARBONNEAUX] If the application (the mod_php/perl/...virtual-to-physical mapping hides the fact we're chrooted, it
doesn't help PHP/Perl/CGI scripts. Users can get confused; I prefer
to have the user thoroughly understand what's going on BEFORE
things start to work, not at some random moment in the future.
application) receve the real path in the chroot. is a problem ? the
developper need only to take care of absolute path set in her code
(like path stored in configuration file), all path are send to
php/perl by apache are real path inside the jail! And can be directly
used by the code...
to the interpreter, but if the script needs to use an absolute path, it
needs to take the jail into account.
CGI are not realy fast option to execute dynamique application... :)
And is so complex to make in place, you must copy all necessary
library in the chroot... all the benefit of the mod_chroot idea are
loosed...
You would be surprised how many big, commercial applications run asAnd is so complex to make in place, you must copy all necessary
library in the chroot... all the benefit of the mod_chroot idea are
loosed...
CGI...
4. It's contains unnecessary code. While I understand your joy in
implementing "var:" prefix for ChrootDir, I believe it's better not
to have extra 34 lines of code at the cost of repeating exactly ONE
path in httpd.conf. In other words,
DocumentRoot /var/www ChrootDir /var/www
(or other way around!) is much better than
DocumentRoot /var/www ChrootDir var:DOCUMENT_ROOT +extra code
+spurious error when they appear in different order
[Mathieu CARBONNEAUX] It's only facility... :)implementing "var:" prefix for ChrootDir, I believe it's better not
to have extra 34 lines of code at the cost of repeating exactly ONE
path in httpd.conf. In other words,
DocumentRoot /var/www ChrootDir /var/www
(or other way around!) is much better than
DocumentRoot /var/www ChrootDir var:DOCUMENT_ROOT +extra code
+spurious error when they appear in different order
usually means *worse* code. It means more bug possibilities. We could
add thousands of features to mod_chroot, but we don't, because they fit
better elsewhere...
I also believe rlimit checks are not necessary. If coredump size
limit is set to zero, we should accept it. It's not our business.
It's definitely not worth the cost of adding autoconf to the mix...
[Mathieu CARBONNEAUX] It's check to verify if try to uselimit is set to zero, we should accept it. It's not our business.
It's definitely not worth the cost of adding autoconf to the mix...
coredumpdirectory with core ulimit set to 0 (the default case of
suse!)... apache say nothing in this case... and no dump done wihtout
information of apache why...
With this check apache stop at starting with error if you use
coredumpdirectory (if you set this directive is why you need to dump!
And you need to have max dump size >0!) with dump size to 0...
happen to think it's not our business. I mean - Apache doesn't check it
for itself, why should WE put this check to mod_chroot, which IS NOT
meant to have anything to do with coredumps?!?
:)
We could also check if all files in DocumentRoot are readable, if the
partition holding coredumps has enough space to store coredumps, if the
directory is writable, etc, etc, etc. But it's not our business.
5. While solving the pidfile problem is really cool, I don't really
like the way it's done. Dear list, what do you think?
[Mathieu CARBONNEAUX] The good whay is to add new hook to apachelike the way it's done. Dear list, what do you think?
before unixd_setup_child... It's the way i would like to suggest to
add in ap 2.x dev trunk in the apache dev list.
compatible... But it would only make sense for Apache 2.0/2.2, see
below.
But for all existing apache binary installlation (specialy in
enterprise situation) where is not possible to recompile apache
code... this way are the only way to do...
because ap child_init hook occure after apache as set the uid with
setuid!
And chroot can only made in uid root...
is why i fake apache by setting the uid to 0 (root) after apache
config (post_config phase) in the last phase before child fork (the
"pre_mpm" hook are juste before child fork, in that lat other apache
module to modify uid before i save it!) in that way the
unixd_setup_child make setuid(0) in place of setuid(the uid) and in
the "child_init hook" i can make the chroot (beceause i'm root!) the
child (and only the child not the master process) and reestablish the
desired uid and late apache to continue normaly...
Again, I understand your reasons, but I don't agree it's the only way.enterprise situation) where is not possible to recompile apache
code... this way are the only way to do...
because ap child_init hook occure after apache as set the uid with
setuid!
And chroot can only made in uid root...
is why i fake apache by setting the uid to 0 (root) after apache
config (post_config phase) in the last phase before child fork (the
"pre_mpm" hook are juste before child fork, in that lat other apache
module to modify uid before i save it!) in that way the
unixd_setup_child make setuid(0) in place of setuid(the uid) and in
the "child_init hook" i can make the chroot (beceause i'm root!) the
child (and only the child not the master process) and reestablish the
desired uid and late apache to continue normaly...
We can leave things as they are now, and refrain from messing with
Apache's internal variables.
Good news for all of us: next version of Apache (2.4) will support
chroot()ing out of the box!
regards,
--
Marek Gutkowski