perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: ACL filesystem incompatibility and potential race condition
Date Wed, 02 Mar 2005 02:55:00 GMT
Damon Buckwalter wrote:
> [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:

Your patch is probably similar to the one Philippe has posted:

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     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message