PERFORCE change 36910 for review

Robert Watson rwatson at
Mon Aug 25 21:02:24 GMT 2003

Change 36910 by rwatson at rwatson_paprika on 2003/08/25 14:02:04

	Finish up more of the NFS section.

Affected files ...

.. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#2 edit

Differences ...

==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/arch-handbook/secarch/chapter.sgml#2 (text+ko) ====

@@ -1727,13 +1727,16 @@
 	permission to mount a file system is explicitly configured by
 	the server administrator by means of the &man.exports.5;
 	configuration file.
-	These protections are implemented XXX
 	Each file system is exported only to explicitly configured hosts;
 	for each configuration line, arbitrary mappings of local and
 	remote users are provided, as well as mount flags indicating,
 	broadly, what types of mounts are permitted (read-only or
-	Once amount has taken place, each file system RPC is accompanied
+	Enforcement of these protections is split between the user mountd
+	process, which reads the <literal>/etc/exports</literal> file
+	and services mount requests, and the kernel NFS implementation,
+	which is informed of the export rules by the mount daemon.
+	Once a mount has taken place, each file system RPC is accompanied
 	by a credential structure approximately equivilent to the local
 	credential structure, consisting of effective uid, effective gid,
 	and a set of additional groups.
@@ -1743,7 +1746,10 @@
 	necessary uid and gid mapping first.
 	In the default configuration, network credentials with a uid of 0
 	are mapped to the "nobody user" to limit the level of privilege
-	given to remote hosts.</para>
+	given to remote hosts.
+	In NFSv2, file permissions and protections are largely
+	implemented by the client system; in NFSv3, the server is
+	queried by the client before permitting most forms of access.</para>
       <para>The NFSv2 and NFSv3 protocols supported by FreeBSD do not
 	provide for cryptographic protection of in-flight RPCs on the
@@ -1767,10 +1773,6 @@
 	name any object in the file system regardless of directory-based
 	protections, so clients must be trusted to locally enforce these
 	protections for this and other reasons.</para>
-probably some mention of file handles and mountpoints
     <sect2 id="secarch-gbde">
To Unsubscribe: send mail to majordomo at
with "unsubscribe trustedbsd-cvs" in the body of the message

More information about the trustedbsd-cvs mailing list