<li><a href="#2.18 Can I klog as two users on"> 2.18 Can I klog as two users on a machine in the same cell?</a></li>
<li><a href="#2.19 What are the ~/._afsXXXX f"> 2.19 What are the ~/.__afsXXXX files?</a></li>
<li><a href="#2.20 How do you set up IP-based"> 2.20 How do you set up IP-based ACLs?</a></li>
+ <li><a href="#2.21 What meaning do the owner,"> 2.21 What meaning do the owner, group, and mode bits have in AFS?</a></li>
+ <li><a href="#2.22 What are "dropboxes"?"> 2.22 What are "dropboxes"?</a></li>
</ul>
</li>
</ul>
**File permissions:** [ User ]
-Unix mode bits for group and other are ignored. The mode bits for the file owner don't work the way they used to.
+Unix mode bits for group and other are ignored. The mode bits for the file owner don't work the way they used to. See also question 2.21.
Users should protect their AFS files with (directory) ACLs only. Just use mode bits to make a file executable.
### <a name="2.20 How do you set up IP-based"></a> 2.20 How do you set up IP-based ACLs?
-See <http://www.duke.edu/~jhv/answers/afs-ip-acls.html>
+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), 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.
+
+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
+ - the owner of a file has implicit read (r) and write (w) rights on a file if that user has insert (i) rights on its parent directory
+- to **read** from a file you must have read (r) rights _and_ at least one of the following must be true:
+ - the file's u+r (user read) bit is set
+ - you are the owner of the file
+ - you are a member of system:administrators
+- to **write** to a file you must have write (w) rights _and_ at least one of the following must be true:
+ - the file's u+w (user write) bit is set
+ - you are the owner of the file
+ - you are a member of system:administrators
+
+- changing mode bits and owner/group:
+ - the fileserver will only allow the mode bits on a file (ugo+rwx) to be changed if the user has write (w) and lookup (l) rights on file's parent directory.
+ - the fileserver will only allow the mode bits on a directory to be changed if the user has delete (d) insert (i) and lookup (l) rights on the directory.
+ - only members of system:administrators can change the owner or group of a file.
+ - only members of system:administrators can change the setuid and setgid bits on a file.
+
+The sticky bit, group of a file, g+rwx, and o+rwx bits are completely ignored by all AFS components. Additionally, the u+rwx bits are ignored on directories.
+
+Newly created files and directories are given an owner numerically equal to the pts identity of the user who created the file or directory. Initial mode bits are assigned by the AFS cilent, typically based on the creating user's umask.
+
+### <a name="2.22 What are "dropboxes"?"></a> 2.22 What are "dropboxes"?
+
+When the ACL on a directory is set to "irl", this creates what is called a "dropbox". In theory, users should be able to deposit files in the directory, but not modify them once deposited.
+
+In practice, the "not modify them once deposited" part is not enforced by the fileserver; only the [[OpenAFS]] client enforces this restriction. Thus, you should not depend on this for security.
+
+Also, note that system:anyuser=irl has additional problems: because dropbox semantics are based on pts identities (see question 2.21), the fileserver cannot distinguish between two unauthenticated users. So, not only can a user come back days later and modify the "dropped" file, but **any** user can modify a file dropped by an unauthenticated user, at any time.
+