httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oezguer Kesim <kesim-apa...@math.fu-berlin.de>
Subject Contribution: SuEXEC Options
Date Thu, 12 Nov 1998 10:40:10 GMT
Hello,

first of all, I kindly ask you to ignore the fact, that I'm quite new to this
mailinglist.  The issue I like to generate a discussion about is the suEXEC
feature of Apache.  So far, suEXEC can only be choosen at compiletime and then
only be used either for <Virtualhosts> or for _every_ ~user .  Furthermore,
the behaviour of suEXEC -- like followsymlinks -- is fixed.

Here are some examples, in which a different policy would be quite effective
and secure:

-    Consider a project with, let's say, n members, which work on an
     WWW-interface for they database.  They are all in one unix-group and each
     one needs write permission to the directory as well to the scripts --
     they share them.
     In that case, I would like to say to Apache:  For _this_ <Directory>,
     enable suEXEC _and_ allow (optionally!!) (sub-)directories beeing
     writable by _group_, as long as the script-owner is a member of it (so,
     no one could have put that script into this directory besides group
     members).
     An option for suEXEC, which allows scripts beeing group-writable (as long
     as the owner is a member of the group!), would be quite usefull, too.

-    Also, I like to tell suEXEC _optionally_, that it should take _secondary_
     groups into account -- since the groups members most likely will not have
     the mentioned group as primary one.
     
-    Following Symlinks for directories are forbidden.  But for scripts?  If
     one could have a _option_ for suEXEC, that for _this special_
     <Directory> it should follow it _as long as_:
     	- both, target and link, are _not_ in a symlinked directory.
	- the uid's of both are identical.
	- the gid's of both are identical, _or_ (optional!) the owner is a
	  member of _both_ groups.

-    At compiletime, I like to select a different DOC_ROOT for suEXEC, let's
     call it SUEXEC_CGI_ROOT, in order to cleanly split usual scripts an
     `trusted' ones -- but for me, whitout suEXEC there is a bigger security
     problem, since any data, which is readable for _one_ script, is readable
     for _every other_ script.

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)

In the last compile-case, you may put the following directives into
access.conf:

<Directory /foo/bar>
Options SuExec SuExecFollowSymLinks SuExecAllowDirectoryWritableByGroup
SuExecAllowProgamWritableByGroup SuExecTrySecondaryGroups
</Directory>

This would enable suEXEC for /foo/bar and change it's behaviour as mentioned
(of course, one has to check the source, to see what it would exactly do).

None of the options are set by default.  Other <Directories> wouldn't
"suEXEC"'lized.

I should point out, that I'm using my own code at a _large_ site (~800 users
and machines), whithout any problems.  I wrote it with respect and full
concentration on security concerns, but would like to let you check it again.

If there is any interest in my patch, the last question is:  Can I post a patch of about 11K
bzip2'ed to this mailing list?

cheers,
  Oezguer Kesim

-- 
Oezguer Kesim       |
Unix Support        |  Email: Oec.Kesim@alcatel.de
Alcatel SEL Berlin  |

Mime
View raw message