Date: Tue, 24 Aug 1999 11:17:03 -0400 From: Christopher Masto <chris@netmonger.net> To: Wes Peters <wes@softweyr.com> Cc: Greg Lehey <grog@lemis.com>, Chuck Robey <chuckr@picnic.mat.net>, 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: <19990824111703.B10650@netmonger.net> In-Reply-To: <37C2ADAD.B1F19098@softweyr.com>; from Wes Peters on Tue, Aug 24, 1999 at 08:35:25AM -0600 References: <19990823223645.A14001@netmonger.net> <Pine.BSF.4.10.9908232256550.49952-100000@picnic.mat.net> <19990823231130.A16133@netmonger.net> <19990824125210.A83273@freebie.lemis.com> <19990823233434.C16133@netmonger.net> <37C2ADAD.B1F19098@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 24, 1999 at 08:35:25AM -0600, Wes Peters wrote: > You've got this so wrong, perhaps you should just go find a System V man > page and read about mandatory locking before embarassing yourself any- > more. First of all, when was it decided that we were all talking about System V? I think that's part of the problem here; some people are arguing whether locking should exist while others are arguing what the semantics should be. I have seen (at least) four ideas mentioned: SysV Root doesn't obey locking Root can override locking Only root can lock So don't insult me for giving a "what if?" example. If it's not a problem under certain semantics, that's good. Let's see if that's the case. > Locking will only block if another process is holding an overlapping lock. > opening won't block due to mandatory locking. The only operations that > can block are read and write, and then only if the read or write operation > will overlap a locked range of bytes. 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. 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/ 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?19990824111703.B10650>