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
