Date: Tue, 30 Jun 1998 09:18:37 -0400 (EDT)
From: Gregory A Lundberg <lundberg@vr.net>
To: Apache Developers <new-httpd@apache.org>
Subject: Re: PR listing, suexec PRs
In-Reply-To: <Pine.BSF.3.95q.980629233206.14616n-100000@valis.worldgate.com>
Message-ID: <Pine.LNX.3.95.980630085440.11791C-100000@gaia.vr.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Mon, 29 Jun 1998, Marc Slemko wrote:

> Just note that some of the anal restrictions that are in place right now
> are there for a reason, and it is very difficult to open it up without
> opening up security risks.  Even the current suexec has a certain level of
> risk in it.

I think you'll find I'm more paranoid than the current suEXEC.  Most of
the changes seem to me to be closing-down rather than openning up.

> > PR 1268
> >   core needs another UID/GID to run CGIs under (per server) so that
> >     system-wide CGIs (ala ScriptAlias) aren't run as the server UID/GID
> >     I agree, I've seend this and wished it weren't so myself.  Dean
> >     seems to agree, too.
> 
> This is a configuration issue; you can do it now just by using
> virtualhosts for all your servers and using a User directive in the vhost.

The idea is to have one UID/GID access the pages and another for running
the CGIs.  Personally, I like using a third to own the pages; for customer
sites, I only allow customers access to the owning-UID (either through
shell or Frontpage, but not through both).  For system-wide CGIs, I've
always wanted yet another UID/GID just to run them so the shared CGIs run
as a completely different user than all other processes on the system; in
particular, as different UID/GIDs than the server.

> > PR 1346
> >   feedback is there marc!  This looks like another take on PR 1268 to
> >     me.  In addition, the requirement that suEXEC only work for ~<user>
> >     has always bothered me.
> 
> You can not just add the ability to run as owner without introducing a lot
> more security risks.

I'm not clear here.  My feeling is the PR s/b closed since the feedback is
there.  What's bothered me is that suEXEC isn't used for non-virtualhost
root webs.  My feeling on this is in my comment above for PR1268.  

Further, if there is some other rule available (say, directory matching)
then suEXEC should be configurable (at compile time) to use that instead
of tidle-users to treat a request as a per-user request.  This, however,
could be such a can of worms, that it may be best left to admins who can
code and not supported, even as an example, in the released code.

> > PR 2022
> >   we've already setuid'd so we can't re-open the error log file.  if
> >     we add syslog capabilities, this is a non-issue.
> 
> It is still an issue because syslog can not, should not, and would not be
> the default.

Yes, syslog s/b an option and the admin s/b aware that it is not always
reliable (or even available).  Seems to me this problem with logging s/b
solvable ; just haven't looked at it much yet. 

----

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              lundberg@vr.net
Kettering, OH 45409-1615 USA    1-800-809-2195