Date: Sun, 3 Aug 1997 13:26:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@dk.tfs.com (Poul-Henning Kamp) Cc: winter@jurai.net, fs@FreeBSD.ORG Subject: Re: Open by Inode# Message-ID: <199708032026.NAA02109@phaeton.artisoft.com> In-Reply-To: <10680.870601110@critter.dk.tfs.com> from "Poul-Henning Kamp" at Aug 3, 97 11:38:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708032026.NAA02109>