Message-ID: <19981114130037.21839@dialup.fu-berlin.de>
Date: Sat, 14 Nov 1998 13:00:37 +0100
From: Oezguer Kesim <kesim-apache@math.fu-berlin.de>
To: new-httpd@apache.org
Subject: Re: Contribution:  SuEXEC Options
References: <19981112114010.A21278@bln.sel.alcatel.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <19981112114010.A21278@bln.sel.alcatel.de>;
 from Oezguer Kesim on Thu, Nov 12, 1998 at 11:39:50AM +0100
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Thus spake Oezguer Kesim (kesim-apache@math.fu-berlin.de):

> I made a implementation of all the things above.  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