PERFORCE change 36910 for review
rwatson at FreeBSD.org
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
==== //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;
- 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
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs