none

diff --git a/AFSLore/AdminFAQ.mdwn b/AFSLore/AdminFAQ.mdwn
index 38da562..b60f199 100644 (file)
--- a/AFSLore/AdminFAQ.mdwn
+++ b/AFSLore/AdminFAQ.mdwn
@@ -61,6 +61,7 @@ The Administration Section of the [[AFSFrequentlyAskedQuestions]].
         <li><a href="#3.50 What is a Shadow?"> 3.50 What is a Shadow?</a></li>
         <li><a href="#3.51 Can I authenticate to my af"> 3.51 Can I authenticate to my afs cell using multiple kerberos Realms?</a></li>
         <li><a href="#3.52  Is it a good idea to store"> 3.52 Is it a good idea to store mail in AFS?</a></li>
+        <li><a href="#3.53  How can I ensure that the"> 3.53 How can I ensure that the userids on client machines match the users' pts ids?</a></li>
       </ul>
     </li>
   </ul>
@@ -1197,3 +1198,7 @@ and recieve the same privileges as if you had run:
 Some people have expressed the opinion that this is not a good idea. Assuming that a modern (one-file-per-message) format is being used, the concrete reasons to avoid storing mail in AFS include:
 
 1. AFS is not designed to provide good performance under the sort of concurrent accesses that occur when many mail server machines share a common space in AFS; see [this message](http://www.openafs.org/pipermail/openafs-info/2007-June/026621.html) for more information. This does not apply to situations where there is a single mail server for a particular user.
+
+### <a name="3.53  How can I ensure that the"></a><a name="3.53  How can I ensure that the "></a> 3.53 How can I ensure that the userids on client machines match the users' pts ids?
+
+You can use [libnss-afs](http://www.hcoop.net/~megacz/software/libnss-afs.html) for this.

diff --git a/AFSLore/UsageFAQ.mdwn b/AFSLore/UsageFAQ.mdwn
index 854aac0..01d3f26 100644 (file)
--- a/AFSLore/UsageFAQ.mdwn
+++ b/AFSLore/UsageFAQ.mdwn
@@ -465,9 +465,9 @@ See [[IPAccessControl]].
 
 ### <a name="2.21 What meaning do the owner,"></a><a name="2.21 What meaning do the owner, "></a> 2.21 What meaning do the owner, group, and mode bits have in AFS?
 
-In order to appear more like a local filesystem, AFS will faithfully store the numeric UID (owner), GID (group), and permission bits (read, write, and execute for user, group, and other), as well as the setuid, setgid, and sticky bits. For the most part, these values are simply recorded and reported back when requested. However, in some instances the fileserver and/or cache manager will make access control decisions based in part on these values.
+In order to appear more like a local filesystem, AFS will faithfully store the numeric UID (owner), GID (group), for both files and directories, as well as the permission bits (read, write, and execute for user, group, and other, plus setuid, setgid, and sticky bits) for files. Note that permission bits for directories are not stored.
 
-The following is believed to be a complete list of those circumstances. Below, "owner" refers to the user whose numeric pts identity is equal to the owner of the file or directory.
+For the most part, these values are simply recorded and reported back when requested. However, in some instances the fileserver and/or cache manager will make access control decisions based in part on these values. The following is believed to be a complete list of those circumstances. Below, "owner" refers to the user whose numeric pts identity is equal to the owner of the file or directory; this might not bear any relationship to the UNIX UID associated with the client process that created the file.
 
 - implicit ACLs
   - the owner of the root directory of a volume has implicit administer (a) rights on all directories in the volume