So then a detection of something like PAM or other authentication facility or a lookup of the UID against /etc/passwd and group to resolve UID to UNAME might be in order? Is there a way around that?
On Fri, 2002-01-04 at 19:59, GUMMALAM,MOHAN (HP-Cupertino,ex2) wrote: > Currently suexec does not seem to work with apache2.0.. well atleast not > completely. The problem I seem to run into is with ~user situations. > Looks > like the suexec code (suexec.c) expects to make a distinction between > ~user > calls from others by inspecting for the "~" character. However, in > os/unix/unixd.c, the userid passed to suexec program is a numerical > string > (string of numbers, corresponding to uid_t of the ~user). As a result, > suexec always bails out for every ~user calls with the following error > message in suexec_log file: > > command (/home/user/public_html/showuser.cgi) not in docroot > (/usr/local/apache2) > > I have made some fix and it works. I could post the patch(es) if > required. > The files changed for this are: > os/unix/unixd.c > os/unix/unixd.h > modules/generators/mod_suexec.c > modules/generators/mod_suexec.h > > 1. Change the return type of get_suexec_id_doer to > unixd_config_rec (originally ap_unix_identity_t). > 2. Modify get_suexec_id_doer to return "user" string > in the cfg->ugid.user_name structure, if the URI contains ~. > 3. Call the suexec program with "~user" string if required, > otherwise call it with uid_t of the user specified in the > SuexecUserGroup directive in httpd.conf (the original behaviour). > > If someone has a better solution, please post it. > Thanks, > M -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: [EMAIL PROTECTED] "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb
signature.asc
Description: This is a digitally signed message part
