From owner-freebsd-hackers Mon Aug 23 12:43:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 33E6415063; Mon, 23 Aug 1999 12:43:06 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA39572; Mon, 23 Aug 1999 15:42:44 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: 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> Date: Mon, 23 Aug 1999 15:43:10 -0400 To: "Daniel C. Sobral" , Greg Lehey From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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