Date: Tue, 24 Aug 1999 23:27:48 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: Greg Lehey <grog@lemis.com>, 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: <37C2ABE4.B2C12DA4@newsguy.com> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <37C174F5.2D8AEEB1@newsguy.com> <v04210103b3e7529e5859@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn wrote: > > There's a difference between a program which has a locking-oversight > or race-condition, and a program you write to deliberately destroy > data. Yep. Intention. But that's all. > 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. A well-intentioned but incorrect mandatory locking can result in data inconsistency because it is not using locking correctly, and thus introducing race conditions, and can also result in dead-locks. It's really quite simple. If the algorithm is correct, both advisory and mandatory locking will work. If the algorithm is not correct, neither will. What mandatory locking provides is a way to lock out anyone who doesn't use locking. The only two situations I can think of for this are incorrect algorithms and intentional behavior. In the first case, you still gain nothing, because mandatory locking is not protecting you from incorrect algorithms, only from those with an error as huge as not using locking at all. In the second case, mandatory locking is useless, as I previously demonstrated. Now, if you know any other situation where mandatory locking results in a different behavior from advisory locking, please feel free to enlighten me. > 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. Actually, I have nothing against having it as an option, as long as root can override it. It opens a pandora box for denial of service attacks, but as long as I, the system manager, can completely disable it (by inaction, preferably), I don't mind. > (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...) Wanna make a bet that if we introduce this feature today we'll still be closing security holes by 2005? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org - Come on. - Where are we going? - To get what you came for. - What's that? - Me. 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?37C2ABE4.B2C12DA4>