Re: Open by inode? (was Re: knfsd)

Alain Williams (addw@phcomp.co.uk)
Sat, 9 Jan 1999 13:02:47 +0000


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/