Messages in this thread | | | Date | Sat, 9 Jan 1999 13:02:47 +0000 | From | Alain Williams <> | Subject | Re: Open by inode? (was Re: knfsd) |
| |
On Thu, Jan 07, 1999 at 10:18:00AM +0000, Jamie Lokier wrote: > There's really no need for extra syscalls for open-by-inode. > > Implement /proc/inode/NNN instead... We then have the problems with which device, ... How about this: * There are several inodes that I 'reserved' (the first 10 I think on ext2), let us use one of them. * Invent an option to mkfs that creates a directory in the root of the file system that is called 'inodes' and has an inode number of 4. * Hack the file system code to handle a directory with an inode of 4 specially: * If you try to open a file in that directory the name will be interpretted as an inode number and yeild that file. * If you try to read (ie 'ls') the directory you get nothing. * If you try to write to the directory (ie 'rm') it fails.
This has the advantage of needing no new system calls, just a small change to the ext2 file system code. It can be secure, the directory can be chowned/chgrped to limmit access, if the sysadmin doesn't want it at all (generally the case) he either removes the directory or doesn't create it in the first place.
> On Wed, Jan 06, 1999 at 12:14:12AM -0500, D. Feuer wrote: > > In other words, make all the system calls inode-based except for some kind > > of lookup(filename) to get the inode. Implement filename-based > > functions in libraries. Has a certain pointy elegance, but > > could seriously mess up the transparency of the fs layer, and faces > > either major atomicity issues (if lib based) or ugly functionality > > duplication in > > syscalls (if, as you recommended, new syscalls just added). For example, > > copying a directory to a different disk and mounting it under might mess > > up poorly-written programs that kept track of the inodes. Ouch! Could be > > an administrative nightmare. But the idea is elegent.... Perhaps trouble > > could be avoided by purposely messing up all the inode numbers at mount > > time (seeded from /dev/random). > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/
-- Alain Williams
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |