8 May 2008 00:15
Re: new version of mod_chroot...
Mathieu CARBONNEAUX <info <at> ch2o.info>
2008-05-07 22:15:15 GMT
2008-05-07 22:15:15 GMT
This is the last version of my mod_chroot hack! if anyone are interest
on it...and testing it...
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
- 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.
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
Mathieu wrote:
>> 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 translation
> (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 :)
>
>> 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 before
> 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.
>> 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/...
> 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 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 as 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... :)
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...
>> 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 use
> 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.
>> 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 apache
> 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.
> 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.
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
RSS Feed