From owner-freebsd-fs Sun Aug 3 01:52:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA14290 for fs-outgoing; Sun, 3 Aug 1997 01:52:04 -0700 (PDT) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA14285 for ; Sun, 3 Aug 1997 01:52:02 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.5/8.8.5) with SMTP id EAA02292 for ; Sun, 3 Aug 1997 04:52:01 -0400 (EDT) Date: Sun, 3 Aug 1997 04:52:00 -0400 (EDT) From: "Matthew N. Dodd" To: fs@freebsd.org Subject: Open by Inode# Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm involved in writing an application that would benefit from the ability to open a file by its inode# rather than its filename. A friend of mine has done something similar under Linux/ext2fs (see http://www.news.erols.com/patches/ext2_inum.diff for details). I envision something like int iopen(ino_t inode, int flags) Obviously file creation via this call would be silly. Is something like this even feasible? /* 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 */ From owner-freebsd-fs Sun Aug 3 02:40:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA16776 for fs-outgoing; Sun, 3 Aug 1997 02:40:21 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.133.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA16718 for ; Sun, 3 Aug 1997 02:39:35 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id LAA10682; Sun, 3 Aug 1997 11:38:31 +0200 (CEST) To: "Matthew N. Dodd" cc: fs@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: Open by Inode# In-reply-to: Your message of "Sun, 03 Aug 1997 04:52:00 EDT." Date: Sun, 03 Aug 1997 11:38:30 +0200 Message-ID: <10680.870601110@critter.dk.tfs.com> Sender: owner-freebsd-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message , "Matthew N. Dodd" writes: > >I'm involved in writing an application that would benefit from the ability >to open a file by its inode# rather than its filename. > >A friend of mine has done something similar under Linux/ext2fs (see >http://www.news.erols.com/patches/ext2_inum.diff for details). > >I envision something like > >int iopen(ino_t inode, int flags) > >Obviously file creation via this call would be silly. > >Is something like this even feasible? Certainly. The easiest way is to hack namei so that a filename of the form '#i[0-9]*' would open by inode. Be aware that this has significant (negative) security impact. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-fs Sun Aug 3 13:28:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA14889 for fs-outgoing; Sun, 3 Aug 1997 13:28:03 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA14869 for ; Sun, 3 Aug 1997 13:28:00 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02109; Sun, 3 Aug 1997 13:26:53 -0700 From: Terry Lambert Message-Id: <199708032026.NAA02109@phaeton.artisoft.com> Subject: Re: Open by Inode# To: phk@dk.tfs.com (Poul-Henning Kamp) Date: Sun, 3 Aug 1997 13:26:53 -0700 (MST) Cc: winter@jurai.net, fs@FreeBSD.ORG In-Reply-To: <10680.870601110@critter.dk.tfs.com> from "Poul-Henning Kamp" at Aug 3, 97 11:38:30 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I'm involved in writing an application that would benefit from the ability > >to open a file by its inode# rather than its filename. > > > >I envision something like > > > >int iopen(ino_t inode, int flags) > > > >Obviously file creation via this call would be silly. > > > >Is something like this even feasible? > > Certainly. The easiest way is to hack namei so that a filename > of the form '#i[0-9]*' would open by inode. > > Be aware that this has significant (negative) security impact. Specifically, directory level and obscurity based security is destroyed because there are no "parent" pointers in the inodes (because of support for hard links), so a reverse traversal from the directory location is not possible. I had to do a similar thing for the NetWare for UNIX server, specifically for the AFP (Macintosh) "file ID" support. The way I provided security was to disallow file "hard links" and maintain a "parent inode pointer". This could be done today for directories for FFS, since directory hard links are not allowed. For file hard links, if you didn't want to disallow them, you would need to support the concept of alias inodes to be used to maintain seperate parent pointers. Only then could you reverse traverse the directory to see if your credentials were allowed at the file. I had to do this anyway to support hierarchy reporting for NetWare "trustee rights" enforcement. This still leaves "security through obscurity" blowing in the wind, but as far as I'm concerned, that's not really a problem. My personal preference on a namespace escape would be to fix the "//" POSIX namespace escape processing (currently, a POSIX namespace escape can not set a per component inherited attribute because of the way cpath component lookups work). Specifically, I would say something like: 1) Use "//namespace/" as a prefix to select the name space "namespace". 2) The "inode" namespace would operate on the terminal path component. 3) To specify a particular mounted FS on which the inode is looked up (which your "iopen()" fails to allow), you would specify a path onto the volume (preferrably, the mount point), and then the inode. For example, if /usr was a seperate mounted FS, to look up the inode 475 on that volume, you would use "//inode//usr/475". Note the doubled second slash. Because the "//" is a namespace escape, the initial trailing "/" terminates the namespace designator. After that, a normal path lookup would occur (potentially a lookup of a relative path, for example). To allow for this, the path following the terminating seperator is not considered to start at the root directory unless the path being looked up in the designated namespace begins with its own "/". This allows for things like traversing directories in an alternate namespace. For example, a "unicode" namespace and a "dos8.3" namespace on a VFAT drive. Or a Mac HFS volume with a "macintosh" and a "prodos" namespace. The default view (at least for now) should be an ISO8859-x eight bit clean "view" onto whatever namespace can best support it (ie: the default for a VFAT volume would be the ISO8859-x view onto the Unicode namespace). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.