On Mon, 2004-02-09 at 14:47 -0800, Stas Bekman wrote: > Philippe M. Chiasson wrote: > > On Sun, 2004-02-08 at 04:03 -0500, Andres Salomon wrote: > > > >>Hi Stas, > >> > >>I was wondering about the status of ACL support for modperl2. The > >>following two urls contain info and patches: > >> > >>http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/%5BPATCH%5D_acl_support_P58252/ > >>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=230439 > >> > >>However, I haven't seen any patches that have been verified to work w/ ACL > >>setups, and don't break w/ non-ACL setups. Have you gotten any success > >>reports on your patch? > >> > > > > > > Well, after reading the threads and getting my box setup with ext3fs > > ACLs, I was able to run basic tests with: > > > > -e somefile > > > > and > > > > use filetest 'access'; > > -e somefile > > > > And as far as I can tell, it works the way I expected it to in every > > case. > > Cool. Does it work for Andres?
Andres, can you try it ? > > So I guess it would be safe to use filetest 'access' in ModPerl-Registry > > (at least on Linux), but I would worry about: > > > > 1. Other Uni*es and Win32 > > What about them? Well, from a glance at pp_sys.c, it seems that Perl will do the right thing and use access() if it's available. Otherwise, using filetest 'access' seems like it would revert to the good old behaviour. I just meant that it could be worth verifying that. Who knows, possibly some platforms _do_ provide access(), but it's behaviour is not identical to the basic filetest operators. > > 2. ACL support in APR/httpd > > Are you talking about internal C calls? I don't think it should affect these. I was asking if some of the apr file operations were using access() internally, so we could have leaveraged off of that instead of using Perl. But a quick grep exposed that apr seems to be using access(), but only in threadproc/unix/proc.c, not using it for the implementation of the apr_file_* stuff. So this issue is void (unless it's worth having access() support in APR) > > 3. When was the filetest.pm module introduced in the Perl core ? > > 5.6.0. I don't know whether Leon will want to backport it to 5.005_04. Well, is that an issue preventing us from using it? > 4. performance. from the filetest manpage: > > There may be a slight performance decrease in the filetests when "use > filetest" is in effect, because in some systems the extended function- > ality needs to be emulated. > > is there a generic way to check whether the fs is acl-enabled? No easy way I can find... > > But, I'd be for using this if it doesn't causes false negatives for > > anybody. (A bit of a problem to write a portable test for it though) > > if you get false negatives that's probably a bug in POSIX::access, no? Yes, but who knows the status of access() on all platforms ? IMHO, if it's there, we should think about using it. After all, I am pretty sure Perl already does a pretty good job at making sure it will work correctly on all platforms it runs on. Just my 0.02$ > __________________________________________________________________ > 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 -- -------------------------------------------------------------------------------- Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B) http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5 Q: It is impossible to make anything foolproof because fools are so ingenious. perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
