From owner-freebsd-hackers Mon Aug 23 12:47:49 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 2ADDC1569B; Mon, 23 Aug 1999 12:47:44 -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 PAA46490; Mon, 23 Aug 1999 15:47:23 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <37C172B7.40AD1029@newsguy.com> References: <37C172B7.40AD1029@newsguy.com> Date: Mon, 23 Aug 1999 15:47:50 -0400 To: "Daniel C. Sobral" , "Daniel O'Connor" From: Garance A Drosihn Subject: Re: Mandatory locking? Cc: Greg Lehey , Garrett Wollman , FreeBSD Committers , FreeBSD Hackers , Poul-Henning Kamp , Matthew Dillon Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:11 AM +0900 8/24/99, Daniel C. Sobral wrote: >Daniel O'Connor wrote: > > I think its a good idea, and hey if people object it can always > > be an option like -> > > > > option NO_MANDATORY_LOCKING > > > > Phew, that was tough. > >When introducing security holes, the default should be the hole >not being present. Ie, reverse that option. If we spent our time thinking about the implementation, maybe we could come up with something which meets the needs of the people who would use mandatory locking, without introducing any kind of security hole. Let's list what the potential security risks are, and see if we can't think our way around them. --- 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