From owner-freebsd-hackers Tue Aug 24 16:24:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 669A81513A; Tue, 24 Aug 1999 16:24:15 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id LAA95098; Tue, 24 Aug 1999 11:33:33 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Tue, 24 Aug 1999 11:33:33 -0400 (EDT) From: Chuck Robey To: Christopher Masto Cc: Wes Peters , Greg Lehey , Garance A Drosihn , "Daniel C. Sobral" , Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Re: Mandatory locking? In-Reply-To: <19990824111703.B10650@netmonger.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Aug 1999, Christopher Masto wrote: > Ok, so that means the program doesn't have to be so poorly written. > It can read part of the file, then go to write it just after User 1 > locks that part of the file, so its write will block until User 1 is > finished, but will still stomp over User 1's data. No need to close > and reopen the file. > > Yes, it's WRONG code. Correct code would aquire a lock before > reading. My understanding of "mandatory locking" means that a program that completely ignores any locking at all, if it tries to grab the locked resource, will sleep until the resource is unlocked. This means that the program is mandatorily forced to obey other program's lock requests. It does not force that program to do it's own locks, but it forces it to respect others. Is that the kind of mandatory locking we're talking about? The rogue program, which doesn't do locking, can have it''s data corrupted, but it cannot corrupt the data for a correctly written program's transaction. So how does mandatory locking help? In this situation, I > don't think it does. And this situation is analogous to "I want to > modify this file without taking it offline, but I need to guarantee > that no other processes are using it." How do you know someone > hasn't, say, opened it in an editor, made some changes, and is about > to save? Especially when that modification occurs spontaneously, > perhaps as part of some recovery process unknown to the user editing > the file. > > I'm sure there are situations where mandatory locking accomplishes > something useful. Are they worth it? (I don't claim to know; if > the problems I thought I pointed out don't really exist, good.) > > More seriously than just being a "useless" feature, I am concerned > about the possibility of opening up security holes with mandatory > locking. BSD Unix does not currently have it.. if I understand > correctly, the kind of locking we're talking about means that if I can > get another user to read a file I own, I can make them block > indefinately. Maybe I can't do anything bad with that.. maybe I can > "only" cause a denial of service.. or maybe I can make a new race > condition in a periodic script. > > By the way, I like the idea of mandatory locking, and I "grew up" on > an OS that had it. > -- > Christopher Masto Senior Network Monkey NetMonger Communications > chris@netmonger.net info@netmonger.net http://www.netmonger.net > > Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ > ---------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | picnic.mat.net: FreeBSD/i386 (301) 220-2114 | jaunt.mat.net : FreeBSD/Alpha ---------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message