Date: Tue, 24 Aug 1999 11:33:33 -0400 (EDT) From: Chuck Robey <chuckr@picnic.mat.net> To: Christopher Masto <chris@netmonger.net> Cc: Wes Peters <wes@softweyr.com>, Greg Lehey <grog@lemis.com>, Garance A Drosihn <drosih@rpi.edu>, "Daniel C. Sobral" <dcs@newsguy.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: <Pine.BSF.4.10.9908241129320.49952-100000@picnic.mat.net> In-Reply-To: <19990824111703.B10650@netmonger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908241129320.49952-100000>