Date: Fri, 15 Jul 2011 12:31:17 +0300 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: freebsd-fs@freebsd.org Subject: Re: request for review of exports.5 update Message-ID: <20110715093117.GA1591@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca> References: <10589627.445480.1310418556785.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 11, 2011 at 05:09:16PM -0400, Rick Macklem wrote: > Hi, > > I've added a few sentences to the exports.5 man page in an effort > to try and clarify how NFSv4 exports work. > > If anyone would like to comment on these changes, it would be > appreciated. Ideally, you are familiar with the FreeBSD /etc/exports > file, but not w.r.t. NFSv4. > > The diff is at: > http://people.freebsd.org/~rmacklem/exports.5.diff > > in case you can't handle looking at the following. (The email > system I use loves to mess with whitespace, etc.) > > Index: usr.sbin/mountd/exports.5 > =================================================================== > --- usr.sbin/mountd/exports.5 (revision 223937) > +++ usr.sbin/mountd/exports.5 (working copy) > @@ -28,7 +28,7 @@ > .\" @(#)exports.5 8.3 (Berkeley) 3/29/95 > .\" $FreeBSD$ > .\" > -.Dd December 3, 2009 > +.Dd July 11, 2011 > .Dt EXPORTS 5 > .Os > .Sh NAME > @@ -72,6 +72,12 @@ > There are three forms of this specification. > The first is to list all mount points as absolute > directory paths separated by whitespace. > +This list of directory paths should be considered an > +``administrative control'', since it only enforced by the > +.Xr mountd 8 > +daemon and not the kernel. > +As such, it only applies to NFSv2, NFSv3 mounts and only w.r.t. the > +client's use of the mount protocol. This is correct about administrative control, but these lines from the documentation do not specify that: 1) entire file system is exported and a client can guess a filehandle and can access any file in exported file system, even if administratively exported subdirectories to NFSv2/3 clients do not allow this; 2) export of nested file systems is insecure, even if a part of one file system is shadowed by another file system a user can guess a filehandle and access any file in a shadowed part; 3) if at least one of mount point components was renamed than this file system cannot be exported, since mountd uses f_mntonname value that is filled when file system is mounted. > The second is to specify the pathname of the root of the file system > followed by the > .Fl alldirs The -alldirs flag does not work as it is defined in exports(5), it worked like this before 1.84 revision of mountd.c. The idea of this flag was not only specifying administratively exported all subdirectories for NFSv2/3 clients, but this flag also specified that this pathname must be considered as a mount point. Now there is no way to specify what is a administratively exported subdirectory and what is a file system. Now if the -alldirs flag is used, then it is used for a file system. E.g. if /var is a file system and if there is line "/var/log -alldirs", then NFSv2/3 client can mount any pathname from /var. > @@ -81,8 +87,19 @@ > .Fl r > option is used on > .Xr mountd 8 . > +For NFSv4, since the ``administrative controls'' are not applied > +because NFSv4 does not use the mount protocol, > +all of the above export line(s) should be considered to have the > +.Fl alldirs > +flag, even if the line is specified without it. Since the -alldirs flag does not work as it is described in exports(5) looks like that this statement can be misunderstood. > The third form has the string ``V4:'' followed by a single absolute path > name, to specify the NFSv4 tree root. > +This line does not export any file system, but simply marks where the root > +of the server's directory tree is for NFSv4 clients. > +The exported file systems for NFSv4 are specified via the other lines > +in the > +.Xr exports 5 > +file in the same way as for NFSv2, NFSv3. > The pathnames must not have any symbolic links in them and should not have > any > .Dq Pa \&. Also I think it is necessary to add description that the -sec option works in a different way as it is defined in exports(5). According to kern/vfs_export.c security flavors are address specification property (struct netcred { netc_secflavors } and vfs_hang_addrlist() function). But when a client sends MOUNT RPC request, then mountd sends a client filehandle with security flavors that were specified last time for exported file system. This is struct exportlist { ex_secflavors } value. As a result a client's security flavors list and the kernel's security flavors list are different.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110715093117.GA1591>