httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Shea <>
Subject RE: suexec: lstat vs stat
Date Fri, 12 Mar 1999 20:00:54 GMT
Hi Jason --

Thanks for the thoughtful analysis.  What you are discussing is
a variation of the suexec patches I maintain.  Nicer in some ways,
more restrictive in others.

I like the idea of allowing User and Group in File/Directory/Location.
I get a similar result by hacking mod_cgi with a new directive, UserId
and GroupId, so that my old mod_cgi_sugid conf files work.  Your approach
is much cleaner.

I'm sending you my 1.3.3 patches under separate cover, you'll find
in there most everything needed to do what you're suggesting.  Hope-
fully it'll help someone.

I need to think about the 'all VHosts home directories under one
directory' thing, it disturbed me enough at one time that my patches
implement a configuration file which specifies the trusted
directories.  I seem to recall believing that for some of my clients
I couldn't make the 'all Vhosts under one' assumption work


On Fri, 12 Mar 1999, Jason A. Dour wrote:
> What you describe is the very CRUX of the problems that us suEXEC Apache
> people ran into many moons ago.  When we first implemented suEXEC, it was
> really easy to add User/Group to VHosts/Userdirs.  Userdirs were handled
> automagically (providing you were using a subdir off of the users unix
> homedir).  VHosts were handled easily by placing all VHosts' homedirs
> under one top-level hierarchy.  Therefore, we knew every top-level
> directory which would essentially be "trusted."
> And so, this form of suEXEC was unleashed upon the world...and there was
> much rejoicing.  Then people began to ask, "What about
> File/Directory/Location support for the User and Group directives?  We
> want suEXEC to give us per location control of the user!"  Us developers
> heard this, and agreed, but there was little rejoicing.
> Adding the User and Group directive to File/Directory/Location was not the
> hard part...we could probably have done that in no time.  The problem came
> in how to handle that at the setuid wrapper layer.  Since we had no secure
> means of authenticating who was running the suexec binary, we had to make
> VERY few assumptions, after which we had to be paranoid as hell.  No
> matter how smart a lot of Apache users are, there are always going to be
> people who either aren't careful enough, or do not understand enough about
> unix security that a less paranoid suEXEC would bite them on the ass.
> So we discussed the issue on new-httpd until we realized that we were
> really spinning our wheels.  Then I think both Randy and myself got really
> busy with Real Life for a little while (or maybe it was just me), and it
> got forgotten for a while.
> It comes down to this...  We need a good/paranoid/low-maintenance means of
> authenticating the server and its data to the setuid layer.  Thinking on
> this now, I think it may be more simple that I once believed it to be...
> Testing to see if the httpd_user is the user running the binary is
> paranoid enough, I would think.  This leaves finding some way of
> "validating" the intended executable with the User/Group provided by the
> This means that Dir/Loc/File disk mappings will still need to fall within
> the main apache top-level directory.  This should be paranoid enough.  I
> mean, if it is paranoid enough for VHosts, it should be paranoid enough
> for Dir/Loc/File.
> After that, we would need the User/Group from the API to match the
> User/Group of the intended executable, AS WELL AS the directory in which
> the intended executable resides.  This should be paranoid enough.  Again,
> what's good for VHosts should work for Dir/Loc/File.
> This would mean no changes to the current suEXEC, and very few changes to
> Apache.  The areas of code that would need to be changed would be:
> http_?core?.c
> 	I'm not certain if http_core has this or not, since I've not
> 	looked at the code in so long.  We would basically need to add
> 	the User/Group directives to the Dir/Loc/File scopes.
> call_exec()
> 	I think call_exec is where we do most of our pre suEXEC
> 	processing.  We would need to add checks for Dir/Loc/File
> 	User/Group directives that would override UserDir/VHost settings.
> That should be it.  I wish I had a better memory about where specific
> pieces of code lie...I hope you can at least find the sections of code I
> am referencing.
> This would solve File/Dir/Loc, but it would still be paranoid enough that
> it shouldn't bite Apache later.  And it would still allow less paranoid
> people to open their servers up with a little bit of programming.
> Amenable?  Would this make people happy?  Do you other AGers still think
> it would be paranoid enough?
> Jason
> # "Jason A. Dour" <>       (
> # Finger for URLs, PGP Key, Geek Code, PJ Harvey info, et cetera.

Gary Shea                             
Salt Lake City            

View raw message