Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Aug 1999 15:43:10 -0400
From:      Garance A Drosihn <drosih@rpi.edu>
To:        "Daniel C. Sobral" <dcs@newsguy.com>, Greg Lehey <grog@lemis.com>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Matthew Dillon <dillon@apollo.backplane.com>, FreeBSD Hackers <hackers@FreeBSD.ORG>, FreeBSD Committers <cvs-committers@FreeBSD.ORG>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Subject:   Re: Mandatory locking?
Message-ID:  <v04210103b3e7529e5859@[128.113.24.47]>
In-Reply-To: <37C174F5.2D8AEEB1@newsguy.com>
References:  <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 1:21 AM +0900 8/24/99, Daniel C. Sobral wrote:
>Well, I'd say advisory lock does the job if the software is written
>right, and if the software is not written right, mandatory locking
>won't help.
>
>Let's give an example. You right a program using mandatory locking
>making access to a file. I write an "incorrect" program accessing
>that file.
>
>I garantee you that the file is going to be screwed up, because I
>intend to write random output to it as soon as I get access to it.
>After all, if I'm incorrect, I'm allowed to do anything.

There's a difference between a program which has a locking-oversight
or race-condition, and a program you write to deliberately destroy
data.

The thing about well-intentioned but incorrect locking code is that
it will appear to work fine, until it trips over the one code path
where it forgets to lock some file that it should have locked.  And
even then, the code will "work" just fine, until multiple processes
are accessing that file at the same time.

I think it is appropriate for an operating system to provide an option
such that *it* (the system) will enforce the locking, and not have to
trust that all code-paths in all programs will do the right thing
WRT advisory locking.

(I also think the implementation needs to be thought out carefully, to
make sure it doesn't become a way for a malicious user to implement
denial-of-service attacks...)


---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04210103b3e7529e5859>