httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Clarke <acla...@civica.com.au>
Subject Re: [users@httpd] howto configure parameterised personal cgi bin
Date Tue, 11 Oct 2005 01:09:43 GMT
On Tue, 11 Oct 2005 03:47, Joshua Slive wrote:
>
> Apache does *not* put the suid bit back.  This must be something in
> your OS.

I still haven't been able to find it, but it's quite irritating. I'm 
starting to think it's part of an integrity-checking ritual somewhere deep 
in the O/S but I cannot find it yet.

> And as I said before, if you don't understand and have a 
> particular need for the effects of suexec, you shouldn't be using it.
> You can simply rm the darn file.

I have tried this and for sure it stops the SUEXEC facet of the calls. I 
doubt the integrity checks will find .suexec2 and rename it...

Is there no parameter that tells Apache not to go via SUEXEC to run CGI? I'm 
a bit surprised that the only way to stop it (without recompiling it out of 
existence) is by hacking the suexec file. People who install from OS 
bundles are left in the cold otherwise.

Now the mode of the users public_html tree must be username:www (my apache 
is running as wwwrun:www) and at least ug+rw if the users CGI is to be 
capable of creating or updating config or data files. I'm comfortable 
setting up a daily cronjob to keep the modes clean, but is ug+rw considered 
risky or acceptable?

>> DirectoryIndex seems to run the CGI script within the cgi bin
>> directory, NOT in the directory you are getting indexed!
>
> This is an expected feature of CGI, as request in the CGI
> specification.

It strikes me as very inconvenient, since at least in the case of 
DirectoryIndex there is a very explicit and obvious working directory for 
the CGI which is not the actual home of the CGI. Personally I would have 
gone for a bit of sleight of hand in the case of DirectoryIndex.

> As you have figured out, you need to look at the env 
> variables passed to the script to see what the original request was.

There's still a weakness in my script that I can't solve yet. If I use the 
DirectoryIndex within DOCUMENT_ROOT (eg http://box/installs), I can use 
that $DOCUMENT_ROOT to determine the filesystem equivalent path. When the 
request is in a userdir, I can detect the http://box/~username and lookup 
via /etc/passwd using (getpwnam $user)[7] in Perl.

But if I want to use the same DirectoryIndex in an <Alias>'d <Directory> 
such as /usr/share/doc (alias "/sharedoc/" for example) that is not below 
the document root, then I do not know how to map the aliased /sharedoc/ to 
it's filesystem path. How can I discover that the REQUEST_URI is under an 
Alias, and what it's value maps to? I am using Perl (not mod_perl yet) so 
if a module can solve it I'm happy to do that.

> To answer your original question, DirectoryIndex can't do substitution
> like you want.  It could be done with mod_rewrite, but it would be
> substantially more complicated.

OK. Complicated in the sense that it's difficult even for a master, or 
complicated in the sense that "you can only solve it easily once you are 
fluent with rewrites"?

-- 
This email is from Civica Pty Limited and it, together with any 
attachments, is confidential to the intended recipient(s) and 
the 
contents may be legally privileged or contain proprietary and 
private information. It is intended solely for the person to 
whom 
it is addressed. If you are not an intended recipient, you may 
not 
review, copy or distribute this email. If received in error, 
please 
notify the sender and delete the message from your system 
immediately. Any views or opinions expressed in this email and 
any 
files transmitted with it are those of the author only and may 
not 
necessarily reflect the views of Civica and do not create any 
legally binding rights or obligations whatsoever. Unless 
otherwise 
pre-agreed by exchange of hard copy documents signed by duly 
authorised representatives, contracts may not be concluded on 
behalf of Civica by email. Please note that neither Civica nor 
the 
sender accepts any responsibility for any viruses and it is your 
responsibility to scan the email and the attachments (if any). 
All 
email received and sent by Civica may be monitored to protect 
the 
business interests of Civica. 


---------------------------------------------------------------------
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-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message