httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@Covalent.NET>
Subject Re: Contribution: SuEXEC Options
Date Sat, 14 Nov 1998 17:33:14 GMT

Just to voice my concerns about suExec...

suExec was intended to be hard to set up and great pains were taken to 
make the wrapper as simple as possible. This was largely because Jason 
and I did not want our names implicated on a weekly CERT advisory
along with Apache. I would urge people to give some thought to an API
for this wrapper and allow other folks to go off and add security
holes to their own wrapper projects until their hearts content.


>  With my patch applied, you
> > can choose between:
> > 	1.)  No suEXEC at all  (i.e without a --enable-suexec)
> > 	2.)  The original suEXEC behaviour  (i.e --enable-suexec and the other
> > 	     original options)
> > 	3.)  suEXEC with options (--with-suexec-opt)
> OK, maybe I didn't make my point clear:
> After my patch applied, one can choose at compiletime between the original
> behaviour and the new one.  Let me elaborate, what the new one actually
> does and which files are affected by the patch:
>   - http_core.h has more OPT_* now.  For this, I had to change the typedef
>     allow_options_t from unsinged char to int.
>   - http_core.c is changed in order to parse the new available options in
>     access.conf.
>   - util_scrip.c is changed so that it calls suEXEC like in the two cases
>     in the original source (i.e ~user or <Virtualhost> with UID and GID
>     set) and now also when `SuExec' is set for this <Directory>.
>     Also, create_argv(), has been changed.  All Options set for a specific
>     <Directory> are given as commandline argument to suEXEC.
>   - Of course, suEXEC has changed:
>     - I wrote a function findtarget(), which tries to find the target of a
>       symlink.  It expects an absolute path (the link) and returns either a
>       absolute path to the target, or NULL.
>     - I wrote a function expand(), which stripes out ../'s, ./'s and /// out
>       from a path.  This function is used within findtarget().
>     - suEXEC now also expects the options set for a <Directory> as
>       commandline argument.
>     - Many if's are added to tune the behaviour of suEXEC in presence of
>       any options related to suEXEC, like:
>       	SuExecFollowSymLinks:
> 		Symlinks of _scripts_ will be followed, as long as
> 			- findtarget() returns a target.
> 			- this target is a regular file.
> 			- the inode and dev_id of target and the
> 			  stat-structure of the `stat()'ed link are
> 			  identical.
> 			- owner uid of link and target match.
> 			- group gid of link and target match, or the
> 			  SuExecTrySecondaryGroups was set and the owner of
> 			  the script is a member of both groups, or the
> 			  SuExecAllowOtherGroups was set.
> 			- both directories (of link and target) are not
> 			  symlinks.
> 			- both directories fullfill the requirements for
> 			  directories (i.e writability check, etc...)
> 	SuExecTrySecondaryGroups:
> 		There are different places, in which suEXEC compares gid's
> 		of files and errors out, if they don't match.  When this
> 		option is set, the gid's may differ, as long as the owner
> 		is a member of both groups given by the gid's.
> 	SuExecAllowDirectoryWritableByGroup:
> 		suEXEC will allow Directories to be writable by group, as
> 		long as the owner of the script is a member of it.  The
> 		SuExecAllowOtherGroups Option doesn't apply in this case
> 		(see below).
> 	SuExecAllowProgramWritableByGroup:
> 		suEXEC will allow scripts to be writable by group, as long
> 		as the owner of the script is a member of it and the of the
> 		group of the directory.  The SuExecAllowOtherGroups Option
> 		doesn't apply in this case (see below).
> 	SuExecAllowOtherGroups:
> 		The last Option (SuExecAllowOtherGroups) is for
> 		compatibility with the original behavior of suEXEC, which
> 		has -- in my opinion -- a bug:  It doesn't check, wether
> 		the owner of a script is actually a member of the group of
> 		the script.  My implementation does, and errors out, when
> 		this is not the case _and_ SuExecAllowOtherGroups was _not_
> 		set.  In consequence of this mentioned `bug', initgroup()
> 		does _not_ set the _primary_ group of a user in the
> 		original source!
> So, what do you think?  IMHO, this is an improvement over the original
> behavior of suEXEC, since sysadmin' have full control over suEXEC on a
> per-<Directory> basis.  Also, you may choose the original behaviour of
> suEXEC and change anything.
> Sure, the code of suEXEC has changed significantly in complexity and size,
> but, hey:  This is a matter of testing.
> cheers,
>   oec

View raw message