httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@Covalent.NET>
Subject Re: [PATCH] suexec.c improvements
Date Thu, 26 Feb 1998 02:02:19 GMT
Martin Kraemer <Martin.Kraemer@mch.sni.de> writes:

> Fix problems of suexec:
> 
> * If log_err()/err_output() could not open the log file, it would bail out.
>   Now it logs to stderr instead (which is usually caught in the error_log).

This was actually intended behavior. The primary concern being the bad 
guy trying to run this from the command line. We would not want it to
run if we could not actually log the event.

> * If the program-to-be-executed mistakenly did not have an execute bit,
>   nothing would be logged. Now the fact is logged (but processing continues)
> 
> * make functions static.
> 
> Open issues:
> 
> * the current directory is determined by a call to getcwd(). Later,
>   this directory name is checked to verify that it is not a symlink.
>   How could it be a symlink?

I've found that I have needed to change the lstat()s to stat()s on my
local version. As for the local directory being a symlink... no.

> * could/should tests like
> 	if (!strncmp("~", target_uname, 1)) { ...
>   be reduced to
> 	if (target_uname[0] != '~') { ...

Is the later more efficient?

>   --and--
> 	if ((dir_info.st_mode & S_IWOTH) || (dir_info.st_mode & S_IWGRP)) {
>   be reduced to
> 	if ((dir_info.st_mode & (S_IWOTH | S_IWGRP)) != 0) {
>   --or is that defensive programming?

This was intended to be defensive. I've not found it very easy to run
under those restrictions though. This comes back to how much we want
to hang ourselves out on this code. Perhaps a compile time option to
reduce the paranoia?



Mime
View raw message