From owner-freebsd-hackers Thu Feb 12 14:49:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19282 for hackers-outgoing; Thu, 12 Feb 1998 14:49:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.31.78.80]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA19099 for ; Thu, 12 Feb 1998 14:48:59 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id RAA14496; Thu, 12 Feb 1998 17:48:41 -0500 (EST) Date: Thu, 12 Feb 1998 17:48:40 -0500 (EST) From: "Matthew N. Dodd" To: Eivind Eklund cc: Charles Owens , hackers list FreeBSD , braam@cs.cmu.edu Subject: Re: Coda FS: FBSD port done!, but development favors Linux In-Reply-To: <19980212185933.22479@follo.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 I for one would love to see this feature (if indeed you are talking about open by inode#). It is highly useful for applications that wish to bypas limitations of FS name lookup (bypass the overhead that is) and implement their own faster indexing directly. News is one such application. (Store article inode# in the overview database and open directly.) For a big fileserver you aren't likely to have local users that could take advantage of the security problems you describe, and CODA will be hidning that information so remote machines won't be able to abuse it either. Of course if we had Veritas or XFS we would have no need to open by inode# as they store their metadata in structures that support high speed lookups by nature. If you wouldn't mind spending the 15 minutes to implement this functionality I for one would be most interested in seeing your patches. Would you be implementing a new open call like say iopen(). Are we even talking about the same thing here? :) On Thu, 12 Feb 1998, Eivind Eklund wrote: > It would take about 15 minutes to create this functionality, and it > has been discussed before. It has been decided against on the basis > of security. This break chroot() completely, and it break the > protection you presently have when > > -rwxr-x--- src/ > -rwxr-xr-x src/somefile > > - somefile will be available to an attacker. > > If this is what it takes to get Coda, I for one won't use it, but I > can probably create and commit a kernel option that give the access > methods so that others can. > > It will not be part of FreeBSD in the default configuration, at least > not if I have any say in the matter. (Sorry to be so brutal, but it > really kill a lot of security assumptions.) /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message