[fbsd] Re: Atomic updates of NFS export lists

Andrey Simonenko simon at comsys.ntu-kpi.kiev.ua
Tue Jun 13 09:18:08 UTC 2006

On Mon, Jun 12, 2006 at 06:24:24PM +0200, Jeremie Le Hen wrote:
> I've been annoyed in the past because I couldn't export two directories
> from the same filesystem with different credentials [1].
> First, where does this limitation come from ?  Then, is it possible to
> remove this limitation without being too intrusive in the VFS code ?
> [1] http://lists.freebsd.org/pipermail/freebsd-net/2005-May/007300.html

In current implementation of NFSv2 and v3 filesystems are exported,
not directories in filesystems.  Suppose you have following

/usr/a -mapall=user1 host1
/usr/b -mapall=user2 host2

/usr/a and /usr/b are in the same filesystem /usr.

To start to work with /usr/a, a client host1 sends the MOUNT request to
mountd.  Mountd verifies that a client is allowed to work with /usr/a
and sends a client special filehandle, which a client will use for
conversation with nfsserver (the kernel part of NFS).  Here the role
of mountd is finished for client host1.

When mountd starts, it parses /etc/exports and says the nfsserver
following configuration:

	-mapall=user1 host1
	-mapall=user2 host2

The kernel knows nothing about settings for directories.  As the result
it verifies if a client is allowed to work with filesystem according
to settings in a filesystem.

Suppose you have:

/usr/a -mapall=user1 host1
/usr/a -mapall=userx host2
/usr/b -mapall=user2 host2

Now there is a conflict, since host2 has two duplicated export
specifications for one filesystem /usr.

Exporting directories in a filesystem is good feature in such
implementation of NFSv2 and v3 for honest hosts, but really is insecure.
You can read more detail description about this at the end of updated

Right now I cannot answer if it is a good or bad idea, or if it is
possible to respect Unix filesystem semantic when putting NFS export
specifications to filesystems' directories, rather than to filesystems.

More information about the freebsd-hackers mailing list