You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/01/05 08:45:57 UTC
symlinks and logfiles
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.
Re: symlinks and logfiles
Posted by Dean Gaudet <dg...@arctic.org>.
Mine fire out of cron... so if it reboots at just the right minute past
the hour... I'm just being pedantic.
Dean
On Sun, 5 Jan 1997, Marc Slemko wrote:
> On Sun, 5 Jan 1997, Dean Gaudet wrote:
>
> > But apache isn't the only thing accessing the logs... rotation scripts
> > need to know about this trickery too.
>
> Only if they want to rotate the logfile between the time when apache dies
> while in that exact bit of startup code, the system reboots when apache is
> starting, etc. and when apache restarts.
>
>
>
Re: symlinks and logfiles
Posted by Marc Slemko <ma...@znep.com>.
On Sun, 5 Jan 1997, Dean Gaudet wrote:
> But apache isn't the only thing accessing the logs... rotation scripts
> need to know about this trickery too.
Only if they want to rotate the logfile between the time when apache dies
while in that exact bit of startup code, the system reboots when apache is
starting, etc. and when apache restarts.
Re: symlinks and logfiles
Posted by Dean Gaudet <dg...@arctic.org>.
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.
> > >
> > >
> >
>
>
Re: symlinks and logfiles
Posted by Marc Slemko <ma...@znep.com>.
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.
> >
> >
>
Re: symlinks and logfiles
Posted by Dean Gaudet <dg...@arctic.org>.
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.
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?
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.
>
>