Re: question on Apache2_4::AuthCookie

[tomcat]

On 07.04.2016 21:12, Lathan Bidwell wrote:


Hi.
I have (a long time ago) created an AAA module based originally on
Apache2::AuthCookie (a copy and rewrite, not a sub-class). Now I need to
adapt this to Apache 2.4.
I have read all the docs at
https://metacpan.org/source/MSCHOUT/Apache-AuthCookie-3.24/lib/Apache2_4/AuthCookie.pm,
and followed the related correspondence on this list.
My problem is that I would like to keep a single perl source, for both
Apache 2.2 and Apache 2.4.
As far as I can tell so far, this should not be a big problem, except for
the following difference :

In the Apache 2.2 version, I have this statement :

use Apache2::Const -compile => qw(:common :http :methods :override :proxy);

and in the Apache 2.4 version, I must have this statement or it will not
compile :

use Apache2::Const -compile => qw(:common :http :methods :override :proxy
AUTHZ_GRANTED AUTHZ_DENIED AUTHZ_DENIED_NO_USER);



I'm not very familiar with require vs use, but could you use a begin
block, Apache2::ServerUtil::get_server_version()
and then if/else based on the version number?



I was kind of thinking in that direction also, but as I recall BEGIN blocks can be kind of 
iffy in an Apache/mod_perl module context.  I'm not an expert either, so I guess I'll have 
to go review some docs about this.

Thanks for the reference to Apache2::ServerUtil::get_server_version(), saves me 
some digging.








(That is because these new AUTHZ_* constants must be used in the new
"AuthzProvider" subs).

I could of course hack the values of these constants under 2.4, and use
their values directly in my module, but that is rather "inelegant".

My question is thus : would there be a way to make the import of these
constants conditional on the Apache version the module is running under ?
(In other words e.g. define them with value 0 initially (for Apache 2.2,
since they are never used there), and override them if under Apache 2.4 ?

Or, to put this another way : imagining that there are already some
servers, currently running Apache 2.2 with, say, mod_perl 2.0.7, and on
which the current (2.2-only) version of my Auth module is running.
If I ever update these servers with the latest (2.4-compatible) version of
my module, including the above extra imported constants, that updated
module will not compile anymore on those systems (because these constants
are not defined there).
Is there a way to avoid this incompatibility ?

I tried to phrase the above as clearly as possible, but if it is still
confusing, I can try again..

Thanks

Re: question on Apache2_4::AuthCookie

[Lathan Bidwell]

>
> Hi.
> I have (a long time ago) created an AAA module based originally on
> Apache2::AuthCookie (a copy and rewrite, not a sub-class). Now I need to
> adapt this to Apache 2.4.
> I have read all the docs at
> https://metacpan.org/source/MSCHOUT/Apache-AuthCookie-3.24/lib/Apache2_4/AuthCookie.pm,
> and followed the related correspondence on this list.
> My problem is that I would like to keep a single perl source, for both
> Apache 2.2 and Apache 2.4.
> As far as I can tell so far, this should not be a big problem, except for
> the following difference :
>
> In the Apache 2.2 version, I have this statement :
>
> use Apache2::Const -compile => qw(:common :http :methods :override :proxy);
>
> and in the Apache 2.4 version, I must have this statement or it will not
> compile :
>
> use Apache2::Const -compile => qw(:common :http :methods :override :proxy
> AUTHZ_GRANTED AUTHZ_DENIED AUTHZ_DENIED_NO_USER);
>
>
I'm not very familiar with require vs use, but could you use a begin
block, Apache2::ServerUtil::get_server_version()
and then if/else based on the version number?

Lathan Bidwell



> (That is because these new AUTHZ_* constants must be used in the new
> "AuthzProvider" subs).
>
> I could of course hack the values of these constants under 2.4, and use
> their values directly in my module, but that is rather "inelegant".
>
> My question is thus : would there be a way to make the import of these
> constants conditional on the Apache version the module is running under ?
> (In other words e.g. define them with value 0 initially (for Apache 2.2,
> since they are never used there), and override them if under Apache 2.4 ?
>
> Or, to put this another way : imagining that there are already some
> servers, currently running Apache 2.2 with, say, mod_perl 2.0.7, and on
> which the current (2.2-only) version of my Auth module is running.
> If I ever update these servers with the latest (2.4-compatible) version of
> my module, including the above extra imported constants, that updated
> module will not compile anymore on those systems (because these constants
> are not defined there).
> Is there a way to avoid this incompatibility ?
>
> I tried to phrase the above as clearly as possible, but if it is still
> confusing, I can try again..
>
> Thanks
>
>

Re: question on Apache2_4::AuthCookie

[Michael Schout]

On 4/6/16 11:51 AM, A. Warnier wrote:
> I could of course hack the values of these constants under 2.4, and use
> their values directly in my module, but that is rather "inelegant".

If you insist on using the same module/source for both 2.4 and 2.2 I  do
not see any other option.

The AUTHZ_GRANTED (and friends) constants simply do not exist in
previous versions of apache.

Regards,
Michael Schout

Re: Thread-safe & vars scope clarification

[Ben RUBSON]

>> If you want to try it yourself and report back, I'm sure we'd all be
>> interested in what you find out. The main thing I'm aware of is that
>> copy-on-write works very well for preforking and threads usually can't
>> match it, but maybe your application is different.
>> 
>> Regarding your thread-safety questions, chdir() is global to the process,
>> so not thread-safe. I think the issue with readdir() is that open directory
>> handles don't get copied when threads are spawned, but maybe there's more
>> to it. The special Perl vars are not a problem with threads, since each
>> thread is a separate interpreter.
>> 
>> You can read about the limitations of threads here:
>> http://perldoc.perl.org/threads.html#BUGS-AND-LIMITATIONS
> 
> File handles, directory handles, cwd, uid, euid, gid, egid, signal 
> mask (%SIG): anything defined in the process struct is shared among 
> all threads. For example, the BSD proc sturuct looks like:
> 
> 
> 
> which gives a rough idea of what is in common.
> 
> The only thing you can do with threads that forks make difficult is 
> having multiple streams of execution working on a common data 
> structure in parallel with about-to-block threads returning control
> before they actually do block. Nice for a web server or database, but
> you probably aren't writing an RDBMS in Perl :-)
> 
> By the time your computing problem has percolated up to the level of
> Perl (vs. C) you are probably better off dealing with the work using
> forks (at least on *NIX) in order to avoid all of the locking, memory,
> and pool-manglement issues. 

Perrin, Steven, sorry for my late answer and thank you very much for your 
clarification and useful links.

So no I'm not writing a RDBMS :) but a filesystem API which of course uses 
readdir().
So according to your answers, threads sound dangerous in this situation.

This link was also very useful to understand how Apache threads work with 
mod_perl :
https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support

The difficulty (from my point of view) seems to have the answer to "is my code 
thread-safe ?".
I did not found an exhaustive list of unsafe functions, and documentation does 
not help much :
"Other usually problematic functions include readdir(), srand(), etc."

In addition, seems to hava exceptions :
Here http://perldoc.perl.org/threads.html#BUGS-AND-LIMITATION, paragraph "Open 
directory handles" :
Seems that opendir() (so readdir() ?) could be thread-safe if system has fchdir 
support.
But how to be sure...

I think I will stay with the classic forked MPM for security reasons :)

Thank you !

Ben