You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 1997/11/04 21:51:22 UTC

FLOCK stuff

I've just started looking at the FLOCK mutex problems... The ``fix''
is pretty easy (having mutex_on do an open()) and having mutex_init
be a noop, but it really opens us up to some nasty DoS attacks.
Work arounds are possible, but all are pretty unpleasant. Sooooo
I'm guessing we should check out FLOCK on all those that
currently use it and make sure it's OK on them.

(A reminder: The key to the problem is that the below does
 not cause any blocking at all:

    flock(fd, LOCK_EX);
    if (fork() == 0) 
	flock(fd, LOCK_EX);  /* one would expect this to block */

 This is due to:
   flock is on files/vnodes and not file-descriptors
   some implementations see the 2nd as "upgrading" an exclusive
    lock _to_ an exclusive lock and that's "OK"
)
-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
            "Look at me! I'm wearing a cardboard belt!"

Re: FLOCK stuff

Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 4 Nov 1997, Dean Gaudet wrote:

> You would want to open() once per child rather than doing it in
> mutex_on()...  It has all the same DoS attacks that sysvsems do... which
> sucks.  If fcntl() works on these platforms we should just use that and
> ditch flock. 

No.  The problem is that the file is sticking around on disk for far
longer.  Apache can give itself a DoS attack if the file already exists,
and that is quite likely if it is started from rc*, etc. where it always
gets the same PID at boot.  An unlink() is necessary.

It is required with fcntl too to be entirely safe, but the window is so
short there that it doesn't matter...

fcntl does not work on all platforms.

> 
> Dean
> 
> On Tue, 4 Nov 1997, Jim Jagielski wrote:
> 
> > I've just started looking at the FLOCK mutex problems... The ``fix''
> > is pretty easy (having mutex_on do an open()) and having mutex_init
> > be a noop, but it really opens us up to some nasty DoS attacks.
> > Work arounds are possible, but all are pretty unpleasant. Sooooo
> > I'm guessing we should check out FLOCK on all those that
> > currently use it and make sure it's OK on them.
> > 
> > (A reminder: The key to the problem is that the below does
> >  not cause any blocking at all:
> > 
> >     flock(fd, LOCK_EX);
> >     if (fork() == 0) 
> > 	flock(fd, LOCK_EX);  /* one would expect this to block */
> > 
> >  This is due to:
> >    flock is on files/vnodes and not file-descriptors
> >    some implementations see the 2nd as "upgrading" an exclusive
> >     lock _to_ an exclusive lock and that's "OK"
> > )
> > -- 
> > ====================================================================
> >       Jim Jagielski            |       jaguNET Access Services
> >      jim@jaguNET.com           |       http://www.jaguNET.com/
> >             "Look at me! I'm wearing a cardboard belt!"
> > 
> 


Re: FLOCK stuff

Posted by Dean Gaudet <dg...@arctic.org>.
You would want to open() once per child rather than doing it in
mutex_on()...  It has all the same DoS attacks that sysvsems do... which
sucks.  If fcntl() works on these platforms we should just use that and
ditch flock. 

Dean

On Tue, 4 Nov 1997, Jim Jagielski wrote:

> I've just started looking at the FLOCK mutex problems... The ``fix''
> is pretty easy (having mutex_on do an open()) and having mutex_init
> be a noop, but it really opens us up to some nasty DoS attacks.
> Work arounds are possible, but all are pretty unpleasant. Sooooo
> I'm guessing we should check out FLOCK on all those that
> currently use it and make sure it's OK on them.
> 
> (A reminder: The key to the problem is that the below does
>  not cause any blocking at all:
> 
>     flock(fd, LOCK_EX);
>     if (fork() == 0) 
> 	flock(fd, LOCK_EX);  /* one would expect this to block */
> 
>  This is due to:
>    flock is on files/vnodes and not file-descriptors
>    some implementations see the 2nd as "upgrading" an exclusive
>     lock _to_ an exclusive lock and that's "OK"
> )
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>      jim@jaguNET.com           |       http://www.jaguNET.com/
>             "Look at me! I'm wearing a cardboard belt!"
>