Date: Sun, 5 Jan 1997 04:27:04 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@hyperreal.com
Subject: Re: symlinks and logfiles
In-Reply-To: <Pine.BSF.3.95.970105012254.18922M-100000@alive.ampr.ab.ca>
Message-ID: <Pine.LNX.3.95dg1.970105042320.11458A-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

But apache isn't the only thing accessing the logs... rotation scripts
need to know about this trickery too.

The group trick I gave below only requires that the webserver not normally
run as that group... not that people not be in it.  The only problem I was
trying to solve was to keep the files from being overwritten by CGIs/etc
started by the server. 

It's just not an easy problem to solve, either technically or through
documentation.  How many people do you think understand that every
executable run by root has to be in a root.wheel owned directory and all
parents must be root.wheel owned?  I bet httpd in some configurations is
owned and writable by user www :) 

Dean

On Sun, 5 Jan 1997, Marc Slemko wrote:

> On Sun, 5 Jan 1997, Dean Gaudet wrote:
> 
> > Ewww! :)  It sucks to "lose" your logfile if there's a system failure
> > between the mv to logs/foo and the mv back.  What if you just hardlink
> > into logs/foo.  Of course then you run into the problem that on some
> > systems a hardlink of a symlink gets the destination of the link, and on
> > others it gets the symlink itself.
> 
> You can have apache detect an aborted attempt when it next starts, and fix
> things up.  There is very minimal risk during the mv (which is actually
> just a rename(), which is atomic (at least under BSD)) so apache should be
> able to recover. 
> 
> I think there are also some race conditions with my suggestion WRT pulling
> the entire directory tree out from under the process after it moves the
> log into the temp directory, but those should only result in the logfile
> ending up in the wrong place.
> 
> > 
> > Another option, equally pointless considering we've agreed people won't
> > read the docs, is to have a wwwlog user who has write perms in the log
> > directory.  Then become that user to open the logs, and return to root
> > before becoming the www user.
> > 
> > Could the same thing be done by becoming www but group wwwlogs, then
> > removing that group before forking the children?
> 
> You could make that work, but it is too complicated (for the user) and
> without ACLs, people often need the one group permission they have on a
> directory for something else.  And people don't read the docs. 
> 
> > 
> > Dean
> > 
> > On Sun, 5 Jan 1997, Marc Slemko wrote:
> > 
> > > I think the following should be a safe way of opening logfiles.  Since
> > > we have no way to do a check and open atomically, we need to make sure
> > > that no one else can play with the file between the check and open.
> > > This can be accomplished by creating a mode 600 directory and
> > > temporarily moving the logfile into there.
> > > 
> > > In mixed-pseudocode:
> > > 	if (mkdir("logs/foo")) whine;
> > > 	chmod logs/foo 600
> > > 	-f logs/logfile && mv logs/logfile logs/foo/logfile
> > > 	# check logs/foo/logfile to see if it is a link, etc.
> > > 	fd = open("logs/foo/logfile", ...)
> > > 	mv logs/foo/logfile logs/logfile
> > > 	rmdir("logs/foo");
> > > 
> > > Now the only race condition (I think) is if someone tries reading the
> > > logfile before it is moved back, it will fail but that shouldn't be a
> > > huge deal.  
> > > 
> > > It is ugly though and I'm not sure it is worth implementing.
> > > 
> > > 
> > 
> 
>