[originally posted to user list, apolgies for duplication]
Greetings,
I use mod_perl 2 on a Debian Linux system, from the Debian supplied package. I also use ext3 and jfs filesystems, which provide ACL capabilites for assigning permissions. In my particular configuration, files are owned by my user and group, and not world-readable. In order for Apache (httpd) to read files to be served, I assign an ACL giving the group that Apache runs as access to read files (www-data on Debian). In the process of doing this, I noted that Apache serves files protected in such a manner without incident, but mod_perl's Registry and PerlRun handlers refuse to.
In an attempt to fix this problem a year ago, I worked to get a patch added on Debian systems that will use the "use filetest 'access'" pragma inside of RegistryCooker. RegistryCooker must also be modified to use $r->filename with the -r and -x filetests, since the "filetest 'access'" pragma requires a filename, not stat() info.
Damon, please take a look at these threads: http://marc.theaimsgroup.com/?t=107623117600001&r=1&w=2 http://marc.theaimsgroup.com/?t=107636627000001&r=1&w=2
Your patch is probably similar to the one Philippe has posted: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107644764027510&w=2
The conclusion remains though: why penalizing users who don't use acls. A cooker subclass sounds like a more efficient solution for the general crowd.
Recently, I found that PerlRun was failing, even with the above patch. This made me look closer at the code in RegistryCooker's can_compile() function. Why are we testing whether the file is readable/executable before compilation, if this operation is not executed atomically with the subsequent ModPerl::Util::slurp_filename()/modperl_util.c:apr_file_open()? This seems to be insecure at worst and unreliable at best.
Not sure what do you find of insecure about it. first of all this is how mp1 registry was written, so mp2 is just a port of the existing code. second registry emulates mod_cgi, so all the checks run by mod_cgi are run by registry. If you are saying that those checks are insecure (later you mention non-atomicness), I believe mod_cgi does the same (I can double check if you want).
Other than that I see no reason why we should require the exec bit on. Though it certainly needs to be readable, no?
I propose that the read/execute/directory tests be removed from can_compile(). The slurp_filename() method should not assume success as it does now, but instead return an error code indicating that a file could not be opened/does not exist/is a directory/etc.
what made your think that slurp_filename doesn't handle errors properly? Take a look at: src/modules/perl/modperl_util.c:
MP_INLINE SV *modperl_slurp_filename(pTHX_ request_rec *r, int tainted)
In the mp2 API we do most error checks on behalf of the user. so in case something goes wrong, it will croak.
This will remove the non-atomicness and will make ACL-protected files work transparently, as they should. This would also make it unnecessary to set the execute bit on non-Win32 systems.
I would supply a patch to do this, but I am not a great C/XS programmer, nor am I highly familar with APR.
I feel it is important that this change makes the official 2.0 release, since other packages do not have similar problems with ACL filesystems (mod_python, Apache Tomcat, PHP).
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
