date:20090929

William A. Rowe, Jr. schrieb:
 Don't forget your BSD vs FSF nonsense...
 
 FSF - http://httpd.apache.org/dev/dist/mod_fcgid/mod_fcgid-2.3.2.tar.gz.md5
 BSD - http://httpd.apache.org/dev/dist/mod_fcgid/mod_fcgid-2.3.2-crlf.zip.md5
naa, already covered:
http://www.gknw.net/phpbb/viewtopic.php?t=570
check my Perl script chkdigest.pl which detects them both automatically ...

Gün.

Re: [vote] release httpd-2.2.14?

Hi,
Jie Gao schrieb:
 /usr/local/src/httpd-2.2.14/srclib/apr/libtool --silent --mode=compile 
 /opt/SUNWspro/bin/cc -g  -fast  -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS 
 -D_REENTRANT -D_LARGEFILE64_SOURCE -DAP_DEBUG
 -I/usr/local/src/httpd-2.2.14/srclib/pcre -I. 
 -I/usr/local/src/httpd-2.2.14/os/unix 
 -I/usr/local/src/httpd-2.2.14/server/mpm/worker 
 -I/usr/local/src/httpd-2.2.14/modules/http 
 -I/usr/local/src/httpd-2.2.14/modules/filters 
 -I/usr/local/src/httpd-2.2.14/modules/proxy 
 -I/usr/local/src/httpd-2.2.14/include 
 -I/usr/local/src/httpd-2.2.14/modules/generators 
 -I/usr/local/src/httpd-2.2.14/modules/mappers 
 -I/usr/local/src/httpd-2.2.14/modules/database 
 -I/usr/local/src/httpd-2.2.14/srclib/apr/include 
 -I/usr/local/src/httpd-2.2.14/srclib/apr-util/include 
 -I/usr/local/src/httpd-2.2.14/srclib/apr-util/xml/expat/lib 
 -I/usr/local/src/httpd-2.2.14/modules/proxy/../generators -I/usr/sfw/include 
 -I/usr/local/src/httpd-2.2.14/modules/ssl 
 -I/usr/local/src/httpd-2.2.14/modules/dav/main -prefer-non-pic -stat
ic -c util_script.c  touch util_script.lo
 util_script.c, line 606: warning: statement not reached

from what I see the Sun compiler is right again:
in util_script.c ap_scan_script_header_err_core() line 431 we have:
while (1) {
this is closed in line 604; and we can only leave the function within
the while loop, thus the 'return OK' in 606 can be removed:

Index: util_script.c
===
--- util_script.c   (Revision 819427)
+++ util_script.c   (Arbeitskopie)
@@ -602,8 +602,6 @@
 apr_table_add(merge, w, l);
 }
 }
-
-return OK;
 }


Gün.

Re: [PATCH-REVIEW] shm.c

Hi,
Guenter Knauf schrieb:
 can you perhaps review and verify if this patch fixes the Sun Studio
 warnings in shm.c?
 http://people.apache.org/~fuankg/diffs/shm.c.diff
 whole file apr/shmem/unix/shm.c:
 http://people.apache.org/~fuankg/diffs/shm.c
 Maybe I did something wrong, but at least it compiled for me on Linux,
 and all tests passed ...
Jie reported already that Sun Studio is calm with it ...
perhaps a critival review from someone (Ruediger?) before I commit?

Gün.

Re: [vote] release httpd-2.2.14?

On Tue, Sep 29, 2009 at 7:00 AM, Guenter Knauf fua...@apache.org wrote:

 Hi,
 Jie Gao schrieb:
  /usr/local/src/httpd-2.2.14/srclib/apr/libtool --silent --mode=compile
 /opt/SUNWspro/bin/cc -g  -fast  -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS
 -D_REENTRANT -D_LARGEFILE64_SOURCE -DAP_DEBUG
  -I/usr/local/src/httpd-2.2.14/srclib/pcre -I.
 -I/usr/local/src/httpd-2.2.14/os/unix
 -I/usr/local/src/httpd-2.2.14/server/mpm/worker
 -I/usr/local/src/httpd-2.2.14/modules/http
 -I/usr/local/src/httpd-2.2.14/modules/filters
 -I/usr/local/src/httpd-2.2.14/modules/proxy
 -I/usr/local/src/httpd-2.2.14/include
 -I/usr/local/src/httpd-2.2.14/modules/generators
 -I/usr/local/src/httpd-2.2.14/modules/mappers
 -I/usr/local/src/httpd-2.2.14/modules/database
 -I/usr/local/src/httpd-2.2.14/srclib/apr/include
 -I/usr/local/src/httpd-2.2.14/srclib/apr-util/include
 -I/usr/local/src/httpd-2.2.14/srclib/apr-util/xml/expat/lib
 -I/usr/local/src/httpd-2.2.14/modules/proxy/../generators -I/usr/sfw/include
 -I/usr/local/src/httpd-2.2.14/modules/ssl
 -I/usr/local/src/httpd-2.2.14/modules/dav/main -prefer-non-pic -stat
 ic -c util_script.c  touch util_script.lo
  util_script.c, line 606: warning: statement not reached

 from what I see the Sun compiler is right again:
 in util_script.c ap_scan_script_header_err_core() line 431 we have:
while (1) {
 this is closed in line 604; and we can only leave the function within
 the while loop, thus the 'return OK' in 606 can be removed:

 Index: util_script.c
 ===
 --- util_script.c   (Revision 819427)
 +++ util_script.c   (Arbeitskopie)
 @@ -602,8 +602,6 @@
 apr_table_add(merge, w, l);
 }
 }
 -
 -return OK;
  }


That is likely to trigger a warning or error from some other compiler.

You could add a comment like /* never reached */ before the return OK so
that anybody who looks at such a warning in the future understands that it
is intentional.

RE: [PATCH-REVIEW] shm.c

2009-09-29 Thread Plüm, Rüdiger, VF-Group

 -Original Message-
 From: Guenter Knauf 
 Sent: Dienstag, 29. September 2009 13:10
 To: dev@httpd.apache.org; APR Developer List
 Subject: Re: [PATCH-REVIEW] shm.c

 Hi,
 Guenter Knauf schrieb:
  can you perhaps review and verify if this patch fixes the Sun Studio
  warnings in shm.c?
  http://people.apache.org/~fuankg/diffs/shm.c.diff
  whole file apr/shmem/unix/shm.c:
  http://people.apache.org/~fuankg/diffs/shm.c
  Maybe I did something wrong, but at least it compiled for 
 me on Linux,
  and all tests passed ...
 Jie reported already that Sun Studio is calm with it ...
 perhaps a critival review from someone (Ruediger?) before I commit?

Looks fine to me. Passes the tests.

Regards

Rüdiger

Re: [vote] release httpd-2.2.14?

2009-09-29 Thread Rainer Jung

On 29.09.2009 13:25, Jeff Trawick wrote:
 On Tue, Sep 29, 2009 at 7:00 AM, Guenter Knauf fua...@apache.org
 mailto:fua...@apache.org wrote:
 
 Hi,
 Jie Gao schrieb:
  /usr/local/src/httpd-2.2.14/srclib/apr/libtool --silent
 --mode=compile /opt/SUNWspro/bin/cc -g  -fast  -DSOLARIS2=10
 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE
 -DAP_DEBUG-I/usr/local/src/httpd-2.2.14/srclib/pcre -I.
 -I/usr/local/src/httpd-2.2.14/os/unix
 -I/usr/local/src/httpd-2.2.14/server/mpm/worker
 -I/usr/local/src/httpd-2.2.14/modules/http
 -I/usr/local/src/httpd-2.2.14/modules/filters
 -I/usr/local/src/httpd-2.2.14/modules/proxy
 -I/usr/local/src/httpd-2.2.14/include
 -I/usr/local/src/httpd-2.2.14/modules/generators
 -I/usr/local/src/httpd-2.2.14/modules/mappers
 -I/usr/local/src/httpd-2.2.14/modules/database
 -I/usr/local/src/httpd-2.2.14/srclib/apr/include
 -I/usr/local/src/httpd-2.2.14/srclib/apr-util/include
 -I/usr/local/src/httpd-2.2.14/srclib/apr-util/xml/expat/lib
 -I/usr/local/src/httpd-2.2.14/modules/proxy/../generators
 -I/usr/sfw/include -I/usr/local/src/httpd-2.2.14/modules/ssl
 -I/usr/local/src/httpd-2.2.14/modules/dav/main -prefer-non-pic -stat
 ic -c util_script.c  touch util_script.lo
  util_script.c, line 606: warning: statement not reached
 
 from what I see the Sun compiler is right again:
 in util_script.c ap_scan_script_header_err_core() line 431 we have:
while (1) {
 this is closed in line 604; and we can only leave the function within
 the while loop, thus the 'return OK' in 606 can be removed:
 
 Index: util_script.c
 ===
 --- util_script.c   (Revision 819427)
 +++ util_script.c   (Arbeitskopie)
 @@ -602,8 +602,6 @@
 apr_table_add(merge, w, l);
 }
 }
 -
 -return OK;
  }
 
 
 That is likely to trigger a warning or error from some other compiler.
 
 You could add a comment like /* never reached */ before the return
 OK so that anybody who looks at such a warning in the future
 understands that it is intentional.

+1 to that, it's not only compilers reading the code. Humans do that to.

mod_fcgid - cannot get authorizer process to be started

The mod_fcgid page says to ask on dev I assume that this is the right 
place to ask.


I'm using mod_fcgid from svn with HTTPD 2.2.

I want to use a fast CGI authorizer to allow me to control access based 
on my rules.

The authorizer needs to be a long running process - never exits.

I know that the fcgid code is noticing the directive because I can 
change the filename

and see the error message from the sources.

But I'm at a lose as to the required to get this configuration to 
actually call my code.

mod_fcgid is not starting up the authorizer process.

I have the following fcgid specific lines in my httpd.conf file:

 httpd.conf 
...
LoadModule fcgid_module modules/mod_fcgid.so
...

Listen *:9000
VirtualHost *:9000
  Location /
  Order allow,deny
  Allow from all
  AuthType Digest
  AuthName Manager System
  Require valid-user
  AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group
  AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd

  FastCgiAuthorizer 
/home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer 


  /Location

  Location /player
#+ HTTP auth file
  Order allow,deny
  Allow from all
  AuthType Digest
  AuthName Manager System
  Require valid-user
  AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group
  AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd
  #- HTTP auth file
  #FCGID

  /Location
/VirtualHost
---

Barry


-
The official User-To-User support forum of the Apache HTTP Server Project.
See URL:http://httpd.apache.org/userslist.html for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: mod_fcgid - cannot get authorizer process to be started

On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott barry.sc...@onelan.co.ukwrote:

 The mod_fcgid page says to ask on dev I assume that this is the right place
 to ask.

 I'm using mod_fcgid from svn with HTTPD 2.2.

 I want to use a fast CGI authorizer to allow me to control access based on
 my rules.
 The authorizer needs to be a long running process - never exits.

 I know that the fcgid code is noticing the directive because I can change
 the filename
 and see the error message from the sources.

 But I'm at a lose as to the required to get this configuration to actually
 call my code.
 mod_fcgid is not starting up the authorizer process.

 I have the following fcgid specific lines in my httpd.conf file:

  httpd.conf 
 ...
 LoadModule fcgid_module modules/mod_fcgid.so
 ...

 Listen *:9000
 VirtualHost *:9000
  Location /
  Order allow,deny
  Allow from all
  AuthType Digest


Did you really mean Digest authentication instead of Basic authentication?

mod_fcgid only supports Basic, AFAICT.

/* Get the user password */
if ((res = ap_get_basic_auth_pw(r, password)) != OK)
return res;

few other compiler warnings .....

Hi,
just for fun I did a compile of the 2.2.x branch on OpenSuSE 11.1-64
with some more gcc warnings than what we normally use:
http://people.apache.org/~fuankg/warnings/conf.sh.txt
result:
http://people.apache.org/~fuankg/warnings/ap22xbuild.txt.gz
while most of them can be ignored, I think at some we should take a look
at, f.e. shadow declarations - these have already biten me with other
projects and compilers ...
cat /tmp/httpd-2.2.x/ap22xbuild.txt | grep warning | wc -l
888
:)

Gün.

Re: [VOTE] release httpd mod_fcgid-2.3.2?

On Mon, Sep 28, 2009 at 11:30 PM, William A. Rowe, Jr.
wr...@rowe-clan.netwrote:

 Quick on the heels of mod_fcgid 2.3.1 we have another candidate for your
 consideration, with many improvements to docs and especially the
 authn/authz
 interface.

 Please fetch up the newly minted mod_fcgid-2.3.2.tar.gz (or bz2)
 or the win32 suitable package mod_fcgid-2.3.2-crlf.zip from:

  http://httpd.apache.org/dev/dist/mod_fcgid/


Thanks!



  [X] +1 to release as 2.3.2-beta


(new directive names need to be agreed to; maybe I can find a way to help)

It is holding up nicely with 32-bit and 64-bit httpd 2.2.x on OpenSolaris
2009.06, and 32-bit httpd 2.0.x and 2.2.x on Ubuntu 8.10.

Re: [vote] release httpd-2.2.14?

2009-09-29 Thread Graham Leggett

Graham Leggett wrote:

   +/-1
   [  ]  Release httpd-2.2.14 as GA

With 6 binding +1's, vote passes.

Will move the binaries across tonight for the mirrors to pick them up,
and will prepare the announcement to go out 24 hours after.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: mod_fcgid - cannot get authorizer process to be started


Jeff Trawick wrote:
On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott barry.sc...@onelan.co.uk 
mailto:barry.sc...@onelan.co.uk wrote:


The mod_fcgid page says to ask on dev I assume that this is the
right place to ask.

I'm using mod_fcgid from svn with HTTPD 2.2.

I want to use a fast CGI authorizer to allow me to control access
based on my rules.
The authorizer needs to be a long running process - never exits.

I know that the fcgid code is noticing the directive because I can
change the filename
and see the error message from the sources.

But I'm at a lose as to the required to get this configuration to
actually call my code.
mod_fcgid is not starting up the authorizer process.

I have the following fcgid specific lines in my httpd.conf file:

 httpd.conf 
...
LoadModule fcgid_module modules/mod_fcgid.so
...

Listen *:9000
VirtualHost *:9000
 Location /
 Order allow,deny
 Allow from all
 AuthType Digest


Did you really mean Digest authentication instead of Basic authentication?

mod_fcgid only supports Basic, AFAICT.

/* Get the user password */
if ((res = ap_get_basic_auth_pw(r, password)) != OK)
return res;



I don't want to be an authenticator, I want to be a authorizer.
Authorizer has no need of passwords right.

Barry

Re: mod_fcgid - cannot get authorizer process to be started

On Tue, Sep 29, 2009 at 11:26 AM, Barry Scott barry.sc...@onelan.co.ukwrote:

 Jeff Trawick wrote:

  On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott 
 barry.sc...@onelan.co.ukmailto:
 barry.sc...@onelan.co.uk wrote:

The mod_fcgid page says to ask on dev I assume that this is the
right place to ask.

I'm using mod_fcgid from svn with HTTPD 2.2.

I want to use a fast CGI authorizer to allow me to control access
based on my rules.
The authorizer needs to be a long running process - never exits.

I know that the fcgid code is noticing the directive because I can
change the filename
and see the error message from the sources.

But I'm at a lose as to the required to get this configuration to
actually call my code.
mod_fcgid is not starting up the authorizer process.

I have the following fcgid specific lines in my httpd.conf file:

 httpd.conf 
...
LoadModule fcgid_module modules/mod_fcgid.so
...

Listen *:9000
VirtualHost *:9000
 Location /
 Order allow,deny
 Allow from all
 AuthType Digest


 Did you really mean Digest authentication instead of Basic authentication?

 mod_fcgid only supports Basic, AFAICT.

/* Get the user password */
if ((res = ap_get_basic_auth_pw(r, password)) != OK)
return res;


 I don't want to be an authenticator, I want to be a authorizer.
 Authorizer has no need of passwords right.


whoops :(

yes

your require valid-user implies that you don't need authorization; try
require valid-group instead

Re: mod_fcgid - cannot get authorizer process to be started


Jeff Trawick wrote:
On Tue, Sep 29, 2009 at 11:26 AM, Barry Scott 
barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote:


Jeff Trawick wrote:

On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott
barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk
mailto:barry.sc...@onelan.co.uk
mailto:barry.sc...@onelan.co.uk wrote:

   The mod_fcgid page says to ask on dev I assume that this is the
   right place to ask.

   I'm using mod_fcgid from svn with HTTPD 2.2.

   I want to use a fast CGI authorizer to allow me to control
access
   based on my rules.
   The authorizer needs to be a long running process - never
exits.

   I know that the fcgid code is noticing the directive
because I can
   change the filename
   and see the error message from the sources.

   But I'm at a lose as to the required to get this
configuration to
   actually call my code.
   mod_fcgid is not starting up the authorizer process.

   I have the following fcgid specific lines in my httpd.conf
file:

    httpd.conf 
   ...
   LoadModule fcgid_module modules/mod_fcgid.so
   ...

   Listen *:9000
   VirtualHost *:9000
Location /
Order allow,deny
Allow from all
AuthType Digest


Did you really mean Digest authentication instead of Basic
authentication?

mod_fcgid only supports Basic, AFAICT.

   /* Get the user password */
   if ((res = ap_get_basic_auth_pw(r, password)) != OK)
   return res;


I don't want to be an authenticator, I want to be a authorizer.
Authorizer has no need of passwords right.


whoops :(

yes

your require valid-user implies that you don't need authorization; 
try require valid-group instead


I want the users password checked and to only proceed if it is valid.
I also want to run the fcgi Authorizer to check that the URL being
access is allowed according to the logic in my Authorizer code.

To that end I have the following:

   Location /
   Order allow,deny
   Allow from all

   # Use digest auth to check the username/password pair
   AuthType Digest
   AuthName Manager System
   # no one gets in without a valid username/password pair
   Require valid-user

   # Use these files to find the passwd and group information
   AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group
   AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd

   # Run the Authorizer.sh to veto URL based on the username
   FastCgiAuthorizer 
/home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh

   /Location

What triggers HTTPD to call the Authorizer.sh code?
Surely not the commands that control authentication checks?

I cannot find Require valid-group defined in the 2.2 docs.

Do you mean I need to add:

 Require group nosuchgroup

And that will cause the mod_authn_user (or what ever module) to try
and match nosuchgroup. When it fails my Authenicator will be run
to see if it can handle that directive?

Isn't this module crying out for a directive like:

   Require fcgid-authenticater-user-is-valid

Barry

Re: mod_fcgid - cannot get authorizer process to be started


Barry Scott wrote:

Jeff Trawick wrote:
On Tue, Sep 29, 2009 at 11:26 AM, Barry Scott 
barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk wrote:


Jeff Trawick wrote:

On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott
barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk
mailto:barry.sc...@onelan.co.uk
mailto:barry.sc...@onelan.co.uk wrote:

   The mod_fcgid page says to ask on dev I assume that this 
is the

   right place to ask.

   I'm using mod_fcgid from svn with HTTPD 2.2.

   I want to use a fast CGI authorizer to allow me to control
access
   based on my rules.
   The authorizer needs to be a long running process - never
exits.

   I know that the fcgid code is noticing the directive
because I can
   change the filename
   and see the error message from the sources.

   But I'm at a lose as to the required to get this
configuration to
   actually call my code.
   mod_fcgid is not starting up the authorizer process.

   I have the following fcgid specific lines in my httpd.conf
file:

    httpd.conf 
   ...
   LoadModule fcgid_module modules/mod_fcgid.so
   ...

   Listen *:9000
   VirtualHost *:9000
Location /
Order allow,deny
Allow from all
AuthType Digest


Did you really mean Digest authentication instead of Basic
authentication?

mod_fcgid only supports Basic, AFAICT.

   /* Get the user password */
   if ((res = ap_get_basic_auth_pw(r, password)) != OK)
   return res;


I don't want to be an authenticator, I want to be a authorizer.
Authorizer has no need of passwords right.


whoops :(

yes

your require valid-user implies that you don't need authorization; 
try require valid-group instead


I want the users password checked and to only proceed if it is valid.
I also want to run the fcgi Authorizer to check that the URL being
access is allowed according to the logic in my Authorizer code.

To that end I have the following:

   Location /
   Order allow,deny
   Allow from all

   # Use digest auth to check the username/password pair
   AuthType Digest
   AuthName Manager System
   # no one gets in without a valid username/password pair
   Require valid-user

   # Use these files to find the passwd and group information
   AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group
   AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd

   # Run the Authorizer.sh to veto URL based on the username
   FastCgiAuthorizer 
/home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh 


   /Location

What triggers HTTPD to call the Authorizer.sh code?
Surely not the commands that control authentication checks?

I cannot find Require valid-group defined in the 2.2 docs.

Do you mean I need to add:

 Require group nosuchgroup


This does not work...


And that will cause the mod_authn_user (or what ever module) to try
and match nosuchgroup. When it fails my Authenicator will be run
to see if it can handle that directive?

Isn't this module crying out for a directive like:

   Require fcgid-authenticater-user-is-valid

Barry




Barry

Re: mod_fcgid

 Ricardo Cantu wrote: 
 
 That's the problem with mod_fcgid right now with out the patch. 
 argv[0] is different but mod_fcgid is not considering it different. It is 
 lumping together by inode only and not paying attention to basename 
(argv[0]). 
 Which can be different when using symbolic links. 
 The patch is so it can properly respect your statement. 

 Ah ha - I misread your statement. 

So, is the patch acceptable?

Re: mod_fcgid - cannot get authorizer process to be started

On Tue, Sep 29, 2009 at 12:51 PM, Barry Scott barry.sc...@onelan.co.ukwrote:

Barry Scott wrote:

Jeff Trawick wrote:

On Tue, Sep 29, 2009 at 11:26 AM, Barry Scott
barry.sc...@onelan.co.ukmailto:
barry.sc...@onelan.co.uk wrote:

Jeff Trawick wrote:

On Tue, Sep 29, 2009 at 8:18 AM, Barry Scott
barry.sc...@onelan.co.uk mailto:barry.sc...@onelan.co.uk
mailto:barry.sc...@onelan.co.uk
mailto:barry.sc...@onelan.co.uk wrote:

The mod_fcgid page says to ask on dev I assume that this is the
right place to ask.

I'm using mod_fcgid from svn with HTTPD 2.2.

I want to use a fast CGI authorizer to allow me to control
access
based on my rules.
The authorizer needs to be a long running process - never
exits.

I know that the fcgid code is noticing the directive
because I can
change the filename
and see the error message from the sources.

But I'm at a lose as to the required to get this
configuration to
actually call my code.
mod_fcgid is not starting up the authorizer process.

I have the following fcgid specific lines in my httpd.conf
file:

httpd.conf
...
LoadModule fcgid_module modules/mod_fcgid.so
...

Listen *:9000
VirtualHost *:9000
Location /
Order allow,deny
Allow from all
AuthType Digest

Did you really mean Digest authentication instead of Basic
authentication?

mod_fcgid only supports Basic, AFAICT.

/* Get the user password */
if ((res = ap_get_basic_auth_pw(r, password)) != OK)
return res;

I don't want to be an authenticator, I want to be a authorizer.
Authorizer has no need of passwords right.

whoops :(

yes

your require valid-user implies that you don't need authorization; try
require valid-group instead

I want the users password checked and to only proceed if it is valid.
I also want to run the fcgi Authorizer to check that the URL being
access is allowed according to the logic in my Authorizer code.

require valid-user means that all it takes to access this resource is a
properly authenticated user.

If mod_authz_user sees valid-user during the authorization stage, it
returns OK and mod_fcgid' authorization hook is not called. You want to
take it further and also run the authorizer, since a properly authenticated
user is not good enough. So require valid-user or require user xxx or
other checks that can be made since the user is already known can't be used.

require valid-group is a hack to bypass checks that the AAA modules know
how to make (require user foo, require group bar, require ldap-group ...,
etc.). There's no provision to allow a FastCGI authorizer app to implement
a particular authorization require-ment. require group foo can also get
you to your authorizer (subject to what the group file module would do). I
haven't checked if that required group name is available to your authorize.

To that end I have the following:

Location /
Order allow,deny
Allow from all

# Use digest auth to check the username/password pair
AuthType Digest
AuthName Manager System
# no one gets in without a valid username/password pair
Require valid-user

mod_authz_user always returns OK from authorization hook with this require

# Use these files to find the passwd and group information
AuthGroupFile /home/bscott/Work/httpd-fcgid-test/auth/http.group

not needed and maybe harmful depending on your require directive

AuthUserFile /home/bscott/Work/httpd-fcgid-test/auth/http.passwd

# Run the Authorizer.sh to veto URL based on the username
FastCgiAuthorizer
/home/bscott/wc/svn/NTB-Next/onelan/DSM/Sources/WebUserInterface/bin/Authorizer.sh

/Location

What triggers HTTPD to call the Authorizer.sh code?
Surely not the commands that control authentication checks?

yes, the require directive; furthermore, if authorization hooks called
before mod_fcgid's think they have answered the question authoritatively,
mod_fcgid won't be called

I cannot find Require valid-group defined in the 2.2 docs.

Do you mean I need to add:

Require group nosuchgroup

This does not work...

because mod_authz_groupfile sees your AuthGroupFile and tries to answer
based on its contents (as well as whether or not that check is authoritative
(see
http://httpd.apache.org/docs/2.2/mod/mod_authz_groupfile.html#authzgroupfileauthoritative))?

And that will cause the mod_authn_user (or what ever module) to try
and match nosuchgroup. When it fails my Authenicator will be run
to see if it can handle that directive?

Isn't this module crying out for a directive like:

Re: mod_fcgid

On Tue, Sep 29, 2009 at 12:51 PM, Ricardo Cantu rica...@smartcsc.comwrote:

  Ricardo Cantu wrote:
 
  That's the problem with mod_fcgid right now with out the patch.
  argv[0] is different but mod_fcgid is not considering it different. It is
  lumping together by inode only and not paying attention to basename
 (argv[0]).
  Which can be different when using symbolic links.
  The patch is so it can properly respect your statement.

  Ah ha - I misread your statement.

 So, is the patch acceptable?


Doesn't the patch require the symlink to reside in the same directory as the
actual executable in order to be effective?

Wouldn't tracking the devno/inode of the link itself (apr_lstat() instead of
apr_stat()) handle the issue more cleanly?  It wouldn't work for hard links,
but it should be a sufficient capability.

As suggested in an earlier mail, why not always fully respect the symlink as
distinct from other filesystem paths that resolve to the same executable
code?

Re: mod_fcgid

On Tuesday 29 September 2009 12:14:51 pm you wrote:
 On Tue, Sep 29, 2009 at 12:51 PM, Ricardo Cantu rica...@smartcsc.comwrote:
   Ricardo Cantu wrote:
  
   That's the problem with mod_fcgid right now with out the patch.
   argv[0] is different but mod_fcgid is not considering it different. It
   is lumping together by inode only and not paying attention to basename
 
  (argv[0]).
 
   Which can be different when using symbolic links.
   The patch is so it can properly respect your statement.
  
   Ah ha - I misread your statement.
 
  So, is the patch acceptable?
 
 Doesn't the patch require the symlink to reside in the same directory as
  the actual executable in order to be effective?
No

 
 Wouldn't tracking the devno/inode of the link itself (apr_lstat() instead
  of apr_stat()) handle the issue more cleanly?  It wouldn't work for hard
  links, but it should be a sufficient capability.
 
 As suggested in an earlier mail, why not always fully respect the symlink
  as distinct from other filesystem paths that resolve to the same
  executable code?
 

Thought about all the possible scenarios and as far as i can see respecting 
basename (argv[0] ) is the one that handles all of them. For instance using 
apr_lstat would interfere with someone who likes to put all executables in one 
directory  then link them to what ever other directory they need it in.

So
/usr/bin/program1
ln -s /usr/bin/program1 /var/www/virtual1/bin/program1
ln -s /usr/bin/program1 /var/www/virtual2/bin/program1

Needs to consider all program1's the same.

On the other hand:

/usr/bin/program1
ln -s /usr/bin/program1 /var/www/virtual1/bin/program2
ln -s /usr/bin/program1 /var/www/virtual2/bin/program3

Needs to consider program1,program2,program3 different.

Re: mod_fcgid

On Tue, Sep 29, 2009 at 3:09 PM, Ricardo Cantu rica...@smartcsc.com wrote:

 On Tuesday 29 September 2009 12:14:51 pm you wrote:
  On Tue, Sep 29, 2009 at 12:51 PM, Ricardo Cantu rica...@smartcsc.com
 wrote:
Ricardo Cantu wrote:
   
That's the problem with mod_fcgid right now with out the patch.
argv[0] is different but mod_fcgid is not considering it different.
 It
is lumping together by inode only and not paying attention to
 basename
  
   (argv[0]).
  
Which can be different when using symbolic links.
The patch is so it can properly respect your statement.
   
Ah ha - I misread your statement.
  
   So, is the patch acceptable?
 
  Doesn't the patch require the symlink to reside in the same directory as
   the actual executable in order to be effective?
 No


got it



 
  Wouldn't tracking the devno/inode of the link itself (apr_lstat() instead
   of apr_stat()) handle the issue more cleanly?  It wouldn't work for hard
   links, but it should be a sufficient capability.
 
  As suggested in an earlier mail, why not always fully respect the symlink
   as distinct from other filesystem paths that resolve to the same
   executable code?
 

 Thought about all the possible scenarios and as far as i can see respecting
 basename (argv[0] ) is the one that handles all of them. For instance using
 apr_lstat would interfere with someone who likes to put all executables in
 one
 directory  then link them to what ever other directory they need it in.

 So
 /usr/bin/program1
 ln -s /usr/bin/program1 /var/www/virtual1/bin/program1
 ln -s /usr/bin/program1 /var/www/virtual2/bin/program1

 Needs to consider all program1's the same.


note that programs in different vhosts are in different classes for other
reasons

what about this example?

/www/foo.example.com/catalog/index.fcgi
/www/foo.example.com/survey/index.fcgi

In general, two commands with the same basename probably aren't the same
application.




 On the other hand:

 /usr/bin/program1
 ln -s /usr/bin/program1 /var/www/virtual1/bin/program2
 ln -s /usr/bin/program1 /var/www/virtual2/bin/program3

 Needs to consider program1,program2,program3 different.

 sure

Re: mod_fcgid

On Tuesday 29 September 2009 1:22:56 pm you wrote:
 On Tue, Sep 29, 2009 at 3:09 PM, Ricardo Cantu rica...@smartcsc.com wrote:
  On Tuesday 29 September 2009 12:14:51 pm you wrote:
   On Tue, Sep 29, 2009 at 12:51 PM, Ricardo Cantu rica...@smartcsc.com
  
  wrote:
 Ricardo Cantu wrote:

 That's the problem with mod_fcgid right now with out the patch.
 argv[0] is different but mod_fcgid is not considering it different.
 
  It
 
 is lumping together by inode only and not paying attention to
 
  basename
 
(argv[0]).
   
 Which can be different when using symbolic links.
 The patch is so it can properly respect your statement.

 Ah ha - I misread your statement.
   
So, is the patch acceptable?
  
   Doesn't the patch require the symlink to reside in the same directory
   as the actual executable in order to be effective?
 
  No
 
 got it
 
   Wouldn't tracking the devno/inode of the link itself (apr_lstat()
   instead of apr_stat()) handle the issue more cleanly?  It wouldn't work
   for hard links, but it should be a sufficient capability.
  
   As suggested in an earlier mail, why not always fully respect the
   symlink as distinct from other filesystem paths that resolve to the
   same executable code?
 
  Thought about all the possible scenarios and as far as i can see
  respecting basename (argv[0] ) is the one that handles all of them. For
  instance using apr_lstat would interfere with someone who likes to put
  all executables in one
  directory  then link them to what ever other directory they need it in.
 
  So
  /usr/bin/program1
  ln -s /usr/bin/program1 /var/www/virtual1/bin/program1
  ln -s /usr/bin/program1 /var/www/virtual2/bin/program1
 
  Needs to consider all program1's the same.
 
 note that programs in different vhosts are in different classes for other
 reasons
 
 what about this example?
 
 /www/foo.example.com/catalog/index.fcgi
 /www/foo.example.com/survey/index.fcgi
 
 In general, two commands with the same basename probably aren't the same
 application.

The patch does not disable the inode/devnode check. So the previous example 
would work as expected. The index.fcgi's are different.

 
  On the other hand:
 
  /usr/bin/program1
  ln -s /usr/bin/program1 /var/www/virtual1/bin/program2
  ln -s /usr/bin/program1 /var/www/virtual2/bin/program3
 
  Needs to consider program1,program2,program3 different.
 
  sure

Re: [mod_fcgid] Cleaning up configuration directive names

I borrowed a few ideas from my friends and botched the rest personally:

(omitting FCGID prefix)

leave alone

AccessChecker
AccessCheckerAuthoritative
Authenticator
AuthenticatorAuthoritative
Authorizer
AuthorizerAuthoritative
Wrapper
MaxRequestsPerProcess
PassHeader

concepts need to be fixed or combined perhaps

ErrorScanInterval - TerminationScanInterval
IdleScanInterval - TerminationScanInterval (yeah, one directive for both
concepts)
ZombieScanInterval (leave alone until processes can be reaped differently)
BusyScanInterval - TimeoutScanInterval

simple adjustment

BusyTimeout - RequestTimeout
IdleTimeout - MaxProcessIdleTime
ProcessLifeTime - MaxProcessLifetime

IPCCommTimeout - IOTimeout
IPCConnectTimeout - ConnectTimeout

DefaultInitEnv - InitialEnv

DefaultMaxClassProcessCount - MaxProcessesPerClass
DefaultMinClassProcessCount - MinProcessesPerClass

MaxProcessCount - MaxProcesses

MaxRequestInMem - MemLimitRequestBody
MaxRequestLen - LimitRequestBody

OutputBufferSize - ResponseBufferSize

PHPFixPathinfoEnable - FixPathinfo

SharememPath - ProcessTableFile
SocketPath - SocketDir

SpawnScore - SpawnScoreSpawnCost
SpawnScoreUpLimit - SpawnScoreLimit
TerminationScore - SpawnScoreExitCost
TimeScore - SpawnScoreDecayPerSecond

Re: [mod_fcgid] Cleaning up configuration directive names

On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote:
 I borrowed a few ideas from my friends and botched the rest personally:
 
 (omitting FCGID prefix)
 
 leave alone
 
 AccessChecker
 AccessCheckerAuthoritative
 Authenticator
 AuthenticatorAuthoritative
 Authorizer
 AuthorizerAuthoritative
 Wrapper
 MaxRequestsPerProcess
 PassHeader
 
 concepts need to be fixed or combined perhaps
 
 ErrorScanInterval - TerminationScanInterval
 IdleScanInterval - TerminationScanInterval (yeah, one directive for both
 concepts)

 ZombieScanInterval (leave alone until processes can be reaped differently)
Working on a patch for this one. Don't want to duplicate work, so let me know 
if anybody else is working on this.

 BusyScanInterval - TimeoutScanInterval
 
 simple adjustment
 
 BusyTimeout - RequestTimeout
 IdleTimeout - MaxProcessIdleTime
 ProcessLifeTime - MaxProcessLifetime
 
 IPCCommTimeout - IOTimeout
 IPCConnectTimeout - ConnectTimeout
 
 DefaultInitEnv - InitialEnv
 
 DefaultMaxClassProcessCount - MaxProcessesPerClass
 DefaultMinClassProcessCount - MinProcessesPerClass
 
 MaxProcessCount - MaxProcesses
 
 MaxRequestInMem - MemLimitRequestBody
 MaxRequestLen - LimitRequestBody
 
 OutputBufferSize - ResponseBufferSize
 
 PHPFixPathinfoEnable - FixPathinfo
 
 SharememPath - ProcessTableFile
 SocketPath - SocketDir
 
 SpawnScore - SpawnScoreSpawnCost
 SpawnScoreUpLimit - SpawnScoreLimit
 TerminationScore - SpawnScoreExitCost
 TimeScore - SpawnScoreDecayPerSecond

Re: Logging or not logging 408's

2009-09-29 Thread Stefan Fritsch

On Monday 28 September 2009, Dan Poirier wrote:
 Is there some good reason not to log the 408's in this case?

I am +1 for logging the 408's. I also think in case of a timeout, 408 
should be logged instead of 400. The attached patch does that.
--- protocol.c.orig	2009-09-05 00:36:31.448689825 +0200
+++ protocol.c	2009-09-05 00:35:43.472690365 +0200
@@ -691,7 +691,12 @@
  len, r, 0, bb);
 
 if (rv != APR_SUCCESS) {
-r-status = HTTP_BAD_REQUEST;
+if (rv == APR_TIMEUP) {
+r-status = HTTP_REQUEST_TIME_OUT;
+}
+else {
+r-status = HTTP_BAD_REQUEST;
+}
 
 /* ap_rgetline returns APR_ENOSPC if it fills up the buffer before
  * finding the end-of-line.  This is only going to happen if it
@@ -877,7 +882,7 @@
 r-read_length = 0;
 r-read_body   = REQUEST_NO_BODY;
 
-r-status  = HTTP_REQUEST_TIME_OUT;  /* Until we get a request */
+r-status  = HTTP_OK;  /* Until further notice */
 r-the_request = NULL;
 
 /* Begin by presuming any module can make its own path_info assumptions,
@@ -916,7 +921,7 @@
 
 if (!r-assbackwards) {
 ap_get_mime_headers_core(r, tmp_bb);
-if (r-status != HTTP_REQUEST_TIME_OUT) {
+if (r-status != HTTP_OK) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
   request failed: error reading the headers);
 ap_send_error_response(r, 0);
@@ -957,8 +962,6 @@
 
 apr_brigade_destroy(tmp_bb);
 
-r-status = HTTP_OK; /* Until further notice. */
-
 /* update what we think the virtual host is based on the headers we've
  * now read. may update status.
  */

Re: [vote] release httpd-2.2.14?

2009-09-29 Thread Graham Leggett

Graham Leggett wrote:

 Will move the binaries across tonight for the mirrors to pick them up,
 and will prepare the announcement to go out 24 hours after.

Still waiting for www.apache.org/dist/httpd to pick up the binaries,
have pinging infra to see if there is anything wrong.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [mod_fcgid] Cleaning up configuration directive names

On Tue, Sep 29, 2009 at 4:59 PM, Ricardo Cantu rica...@smartcsc.com wrote:

 On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote:

  ZombieScanInterval (leave alone until processes can be reaped
 differently)
 Working on a patch for this one. Don't want to duplicate work, so let me
 know
 if anybody else is working on this.


not me

I hope that, for Unix, processes can be reaped as with the MPMs: instead of
asking if a specific pid has exited (for each pid in the list), ask if any
pid has exited and if so find it in the list and handle.

Re: [mod_fcgid] Cleaning up configuration directive names