[Jeffrey Hutzelman <jhutz+@cmu.edu>] Re: Open by inode? (was Re: knfsd)

[Magnus Ahltorp]

FYI.

------- Start of forwarded message -------
Date: Thu, 14 Jan 1999 00:41:47 -0500 (EST)
From: Jeffrey Hutzelman <jhutz+ at cmu.edu>
Reply-To: Jeffrey Hutzelman <jhutz+ at cmu.edu>
Subject: Re: Open by inode?  (was Re: knfsd)
To: Magnus Ahltorp <map at stacken.kth.se>
cc: Linus Torvalds <torvalds at transmeta.com>, linux-kernel at vger.rutgers.edu
Message-ID: <ML-2.3+1.916292507.2754.jhutz at minbar.fac.cs.cmu.edu>

> > Note that open-by-inode() is fundamentally broken, and will not be
> > implemented. There are several reasons:
> > 
> >  - it bypasses directory-based security.
> 
> This is irrelevant for root.

True.  The approach we've been working on to provide this capability for
AFS fileservers (as well as others who want it; I have a couple in mind)
restricts icreate/iopen/iinc/idec to root.

> >  - it breaks any filesystems that don't work by inode number. For
> >    example, a number of filesystems _need_ to know the full pathname:
> >    any well-thought-out network filesystem (and no, I don't consider NFS
> >    to be well-thought-out) will use pathnames, and even local
> >    filesystems like a basic cdrom filesystem needs to know the full path
> 
> Both AFS and Coda have a 4*32bit identifier on each file. Therefore,
> don't call it open_by_inode(), call it open_by_handle(), it is much
> more general.

The problem is that it's not general - it's very AFS-specific, and
requires the underlying filesystem to provide a new indexing mechanism
to support it.  Further, AFS does not actually want that - it already
keeps track of the inode number for each of its files, specifically
to _avoid_ using any name-lookup mechanism provided by the filesystem.
Thus, iopen() is better for AFS.

Linus is correct - generic iopen support does not belong in the VFS
layer, because the concept of inode numbers is not generic.  The
approach we've been working on for AFS involves already having some
file descriptor open on the filesystem you're interested in, and doing
ioctl's on it to create and open other files by inode.  This has the
advantage that it can be done entirely within those filesystems that
care to support it, without the need to provide filesystem-dependent
functionality in the supposedly filesystem-independent VFS layer.

This is very likely the approach that AFS will use, unless we run
into unforeseen problems.  I'll also be using it in a lightweight
AFS fileserver I'm working on, which provides access to the contents
of a workstation's local filesystem to other AFS clients.  I'd also
like to see Coda and the KTH group make use of the same interface,
but obviously I don't have any control over those groups.  Feel free
to contact me via private mail if you'd like to talk about unifying
these efforts.


Below is an example of how our interface will work.  The real thing is
a bit more complicated at this point, but what I've included here should
get the idea across.

fd = open("/vicepa", O_RDONLY);

i = ioctl(fd, I_CREATE, 0);      /* create a file; returns inode */
fd2 = ioctl(fd, I_OPEN, i);      /* open file by inode */

ioctl(fd2, I_INCDEC, 1);         /* increases link count */
ioctl(fd2, I_INCDEC, -1);        /* decreases it */
ioctl(fd2, I_INCDEC, -1);        /* decrease again, now link count is 0 */
close(fd2);                      /* so file is deleted on close */


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


------- End of forwarded message -------