RFC: 9p filesystem interface

RFC: 9p filesystem interface

[Latchesar Ionkov]

Hi,

Translating Plan9's 9P protocol to the Unix world is not very
straightforward task. We already have the basic functionality implemented,
but there are still some missing pieces:

User authentication

  9P protocol requires every user the authenticate separately to the server.
  There is not defined authentication protocol, 9P assumes that the
  client knows what authentication is required by the server. The
  authentication is performed by creating an authentication channel to the 
  server and reading/writing on it. When the auth conversation is done, the
  client "attaches" to the server passing the authentication channel id. We
  don't want to hardcode any specific auth protocol in the kernel, we would
  rather have a way to expose the per-user per-mount authentication channel
  to the user space and let a program take care of the authentication. We
  are discussing whether to do on-demand, user-initiated authentication, or
  both. Currently v9fs attaches as a single user and the file operations for
  all users are done with that user name. 

Error mapping

  In the 9P protocol all errors are reported as textual strings. VFS expects
  errors to be numeric values. Different file servers return different error
  names, there is no common set of error names. We need a way to configure
  v9fs of the mapping for particular file server. Currently v9fs has a static
  mapping of the error names found in the most used file servers.

User mapping

  Users and groups in 9P are also identified by textual strings. VFS expects
  numeric uids. We need a way to configure a mapping between the user names
  and user ids. Currently we don't do any mapping.


We need a per-v9fs-mount interface that we can use for authentication, error
and user mapping. We are evaluating three options -- adding v9fs tree in
procfs, adding v9fs tree in sysfs, and defining a special directory on the
root level of the tree served by v9fs.

Procfs

  If we implement procfs interface, we would add a new directory -- fs/v9fs.
  The top level will contain the global configuration options for the fs.
  There will be subdirectories that will contain the files used to configure
  the specific mounts. When an unauthenticated user tries to perform a file
  operation on an v9fs file, v9fs will create a file in fs/v9fs/nnn
  directory that can be used for authenticating that user.

  Pros: It is going to use existing kernel framework.
  Cons: Having chroot, mount --bind, multiple mounts on the same mount-point
    etc., it is going to be hard to find out which fs/v9fs/nnn subdirectory
    belongs to which tree.

Sysfs
  Sysfs is similar to procfs, but it has one more disadvantage: there is a
  limit of the size of the files. There is no guarantee how much data will
  be tranferred during the authentication conversation. We can work around
  that restriction by doing lseek(fd, 0, SEEK_SET) before we read from the
  authentication file exposed in sysfs, but it is ugly and against common
  sense.

Special directory 
  The third option is to expose the files as a special directory in the roots
  of the trees served by v9fs. The directory (.9p or #9p) is going to behave
  differently than the rest of the files v9fs serves. The files in the
  directory will be handled by v9fs locally and will be used for
  authentication, error and user mapping.

  Pros: It is easier to find the files for a specific mount.
  Cons: Having special files that behave differently may lead to some
    confusion.

We would like to get your opinions on what is the preferred linux-kernel way
of implementing the 9p-to-user-space interface.

Thanks,
	Lucho