-## <a name="2 Using AFS"></a> 2 Using AFS
+[[!toc levels=3]]
+
+## 2 Using AFS
The Usage Section of the [[AFSFrequentlyAskedQuestions]].
- [[PreambleFAQ]]
- [[GeneralFAQ]]
-
-<div>
- <ul>
- <li><a href="#2 Using AFS"> 2 Using AFS</a><ul>
- <li><a href="#2.01 What are the differences b"> 2.01 What are the differences between AFS and a unix filesystem?</a></li>
- <li><a href="#2.02 What is an AFS protection"> 2.02 What is an AFS protection group?</a></li>
- <li><a href="#2.03 What are the AFS defined p"> 2.03 What are the AFS defined protection groups?</a></li>
- <li><a href="#2.04 What is an AFS access cont"> 2.04 What is an AFS access control list (ACL)?</a></li>
- <li><a href="#2.05 What are the AFS access ri"> 2.05 What are the AFS access rights?</a></li>
- <li><a href="#2.06 What is pagsh?"> 2.06 What is pagsh?</a></li>
- <li><a href="#2.07 Why use a PAG?"> 2.07 Why use a PAG?</a></li>
- <li><a href="#2.08 How can I tell if I have a"> 2.08 How can I tell if I have a PAG?</a></li>
- <li><a href="#2.09 Can I still run cron jobs"> 2.09 Can I still run cron jobs with AFS?</a></li>
- <li><a href="#2.10 How much disk space does a"> 2.10 How much disk space does a 1 byte file occupy in AFS?</a></li>
- <li><a href="#2.11 Is it possible to specify"> 2.11 Is it possible to specify a user who is external to the current AFS cell on an ACL?</a></li>
- <li><a href="#2.12 Are there any problems pri"> 2.12 Are there any problems printing files in /afs?</a></li>
- <li><a href="#2.13 Can I create a fifo (aka n"> 2.13 Can I create a fifo (aka named pipe) in /afs?</a></li>
- <li><a href="#2.14 If an AFS server crashes,"> 2.14 If an AFS server crashes, do I have to reboot my AFS client?</a></li>
- <li><a href="#2.15 Can I use AFS on my diskle"> 2.15 Can I use AFS on my diskless workstation?</a></li>
- <li><a href="#2.16 Can I test for AFS tokens"> 2.16 Can I test for AFS tokens from within my program?</a></li>
- <li><a href="#2.17 What's the difference betw"> 2.17 What's the difference between /afs/cellname and /afs/.cellname?</a></li>
- <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>
- <li><a href="#2.23 Can I access a RW-Volume">2.23 Can I access a RW-Volume using the RO-Path ?</a></li>
- </ul>
- </li>
- </ul>
-</div>
-
- [[AdminFAQ]]
- [[ResourcesFAQ]]
- [[AboutTheFAQ]]
- [[FurtherReading]]
-### <a name="2.01 What are the differences b"></a> 2.01 What are the differences between AFS and a unix filesystem?
+### 2.01 What are the differences between AFS and a Unix filesystem?
-Essentially, from a user's point of view, there is little difference between AFS and local unix filestore. Nearly all the commands normally used to access local files can be used to access files in /afs.
+Essentially, from a user's point of view, there is little difference between AFS and local Unix filestore. Nearly all the commands normally used to access local files can be used to access files in `/afs`.
In the following set of sections, I have attempted to "target" each section to an appropriate type of user by including to the right of each section heading one of: User, Programmer, [[SysAdmin]].
**Authentication:** [ User ]
-Before a user can access protected AFS files (s)he needs to become authenticated to AFS using the klog command (Kerberos login) to get a Kerberos "ticket granting ticket" (called a token from here on).
+Before a user can access protected AFS files (s)he needs to become
+authenticated to AFS using the `klog` command (Kerberos login) to get an AFS
+token. Or, a user can run `aklog` to convert existing krb5 tickets into an AFS
+token.
-Without a token, an unauthenticated user is given the AFS identity "system:anyuser" and as such is only able to access files in directories that have ACLs granting system:anyuser access.
+Without a token, an unauthenticated user is given the AFS identity `system:anyuser`, and as such is only able to access files in directories that have ACLs granting `system:anyuser` access.
-Many systems have the klog function built into the system login program. So a user would not even have to know they gain a token on logging in. If you use a system where you have to issue the klog command after login then you should run the pagsh command first (see below).
+Many systems have the `klog`/`aklog` functionality done integrated into their login procecedure. If you use a system where you have
+to issue the `klog`/`aklog` command after login, then you may want to run the `pagsh` command first (see below).
AFS provides access control lists to give more precise control to users wishing to protect their files (see AFS ACL below).
**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. See also question 2.21.
+Unix mode bits on files are usually ignored. The exception to this are the "owner" bits, which can be used to remove access for almost everyone accessing the file (that is, if you remove the "w" bit from the owner permissions, almost nobody can write to the file).
-Users should protect their AFS files with (directory) ACLs only. Just use mode bits to make a file executable.
+Instead of Unix mode bits, you should generally use AFS ACLs to protect your data (see below).
**Data protection with AFS ACLs:** [ User ]
-Some versions of unix (eg IBM's AIX version 3) allow ACLs on local files. In AFS, ACLs protect directories and used with AFS protection groups (see below) provide a finer granularity of protection than can be achieved with basic unix file permissions. (AFS ACLs are described in more detail below.)
+Some versions of Unix (e.g. IBM's AIX version 3) allow ACLs on local files. In AFS, ACLs protect directories and used with AFS protection groups (see below) provide a finer granularity of protection than can be achieved with basic Unix file permissions. (AFS ACLs are described in more detail below.)
**Protection groups:** [ User ]
-Users can create and maintain their own protection groups in AFS - as opposed to unix where only sys admins can manage protection groups.
+Users can create and maintain their own protection groups in AFS - as opposed to Unix where only sysadmins can manage protection groups.
**Hard links:** [ User ]
-In AFS, hard links (eg: ln old new) are only valid within a directory. This is because AFS ACLs protect directories (not individual files) and allowing hard links that span directories would subvert ACL protection.
+In AFS, hard links (`ln old new`) are only valid within a directory. This is because AFS ACLs protect directories (not individual files), and allowing hard links that span directories would subvert ACL protection.
-Symbolic links work in AFS because they reference a pathname and not an i-node directly. (Hard links reference an i-node directly.)
+Symbolic links work in AFS because they reference a pathname and not an inode directly. (Hard links reference an inode directly.)
**Changing file protection by moving a file:** [ User ]
-Moving a file to a different directory will change the protection of a file if the ACL on the new directory if different to the ACL on the original directory.
+Moving a file to a different directory will change the protection of a file if the ACL on the new directory is different from the ACL on the original directory.
**chown and chgrp:** [ User ]
-Only members of the AFS group "system:administrators" can use these commands on files in /afs.
+Only members of the AFS group `system:administrators` can use these commands on files in `/afs`. Note that these are only used by non-AFS-aware Unix utilities; AFS itself does not use these values, but instead uses the AFS ACL.
**Save on close:** [ Programmer ]
-AFS Cache Manager does not send file modifications to a file server until the close() or fsync() system call.
+The AFS Cache Manager does not send file modifications to a file server until a `close()` or `fsync()` system call is performed. `write()` system calls only update the local cached copy on the client.
-write() system calls only update the local cache copy on the client.
+Note the difference in semantics of writing a file:
-Note the difference in semantic of writing a file:
-
-<table border="1" cellpadding="0" cellspacing="0">
+<table border="1">
<tr>
- <th bgcolor="#99CCCC"><strong> local unix file: </strong></th>
- <td> writes update the file "immediately" </td>
+ <th bgcolor="#99CCCC"><strong>local Unix file</strong></th>
+ <td>writes update the file immediately</td>
</tr>
<tr>
- <th align="center" bgcolor="#99CCCC"><strong> AFS file: </strong></th>
- <td> local cached copy updated "immediately" but the server copy is only updated when the file is closed or fsync'ed. </td>
+ <th align="center" bgcolor="#99CCCC"><strong>AFS file</strong></th>
+ <td>local cached copy updated immediately but the server copy is only updated when the file is `close`d or `fsync`ed</td>
</tr>
</table>
-It is important to understand that most applications (eg: vi, emacs, frame, interleaf, wingz, dogz, etc) issue the close() system call when the user chooses/issues the "save" command in the application.
-
-Users are not required to exit the application to "save" their changes back to the server.
+It is important to understand that most applications (`vi`, `emacs`, `frame`, `interleaf`, `wingz`, `dogz`, etc.) issue the `close()` system call when the user chooses/issues the "save" command in the application.
-**byte-range file locking:** [ Programmer ]
+Users are not required to exit the application to save their changes back to the server.
-AFS does not support byte-range locking within a file, although lockf() and fcntl() calls will return 0 (success). The first time a byte-range lock is attempted, AFS will display:
+**Byte-range file locking:** [ Programmer ]
-"afs: byte-range lock/unlock ignored; make sure no one else else is running this program."
+AFS does not support byte-range locking within a file, although `lockf()` and `fcntl()` calls will return 0 (success). The first time a byte-range lock is attempted, AFS will display
-**whole file locking:** [ Programmer ]
+ afs: byte-range lock/unlock ignored; make sure no one else else is running this program.
-AFS does support advisory locking an entire file with flock(). Processes on the same client workstation that attempt to lock a file obey the proper locking semantics.
+There are a couple of platform-specific exceptions to this behavior. Currently (as of 1.6.2), Linux clients will enforce byte-range file locks for processes on the local client only. In addition, Windows clients attempt to simulate byte-range locks for local processes, and acquire full-file locks on the fileserver when a byte-range lock is requested.
-Processes on different AFS clients requesting a lock on the same file would get EWOULDBLOCK returned.
+Server-side byte range locking requires a protocol change, which is currently under consideration.
-**character and block special files:** [ [[SysAdmin]] ]
+**Whole-file locking:** [ Programmer ]
-AFS does not support character and block special files. The mknod command does not create either character or block special files in /afs.
+AFS supports advisory locking of an entire file with `flock()`. Processes on the same client workstation that attempt to lock a file obey the proper locking semantics. Processes on different AFS clients requesting a lock on the same file would get `EWOULDBLOCK` returned.
-**AFS version of fsck:** [ [[SysAdmin]] ]
+**Character and block special files:** [ [[SysAdmin]] ]
-On an AFS server, the partitions containing served files are NOT unix filesystems and standard fsck **must** not be used - use the AFS version instead.
+AFS does not support character and block special files. The `mknod` command does not create either character or block special files under `/afs`.
-### <a name="2.02 What is an AFS protection"></a><a name="2.02 What is an AFS protection "></a> 2.02 What is an AFS protection group?
+### 2.02 What is an AFS protection group?
A named list of users.
Group names are used in AFS ACLs to identify lists of users with particular access permissions.
-In AFS, users can create and maintain their own protection groups. This is different to unix where only the system administrator can manage /etc/group.
+In AFS, users can create and maintain their own protection groups. This is different to unix where only the system administrator can manage `/etc/group`.
-AFS groups are stored in the protection database on fileserver(s) and managed by using the "pts" command.
+AFS groups are stored in the protection database on fileserver(s) and managed by using the `pts` command.
-An AFS group typically has the format:
+An AFS group typically has the format `owner-id:group-name`. By default, only the owner of a group can change its members.
-- owner-id:group-name
+It is possible to have both users and IP addresses as members of an AFS group. By using an IP address like this you can specify all the users from the host with that IP address. Note that IP address membership is insecure, due to the possibility of packet spoofing and the inability of current AFS protocols to protect server communications that do not involve a user-based security token; the `rxgk` security protocol currently under development will enable token-protected access at the client machine level as well as the user level.
-By default, only the owner of a group can change its members.
+### 2.03 What are the AFS-defined protection groups?
-It is possible to have both users and IP addresses as members of an AFS group. By using an IP address like this you can specify all the users from the host with that IP address.
-
-### <a name="2.03 What are the AFS defined p"></a> 2.03 What are the AFS defined protection groups?
-
-- system:anyuser
+- `system:anyuser`
- Everyone who has access to an AFS client in any cell that is on the same network as your cell.
-- system:authuser
- - Everyone who has access to an AFS client in any cell that is on the same network as your cell **and** has valid tokens for your cell (ie has been authenticated in your cell).
+- `system:authuser`
+ - Everyone who has access to an AFS client in any cell that is on the same network as your cell **and** has valid tokens for your cell (i.e. has been authenticated in your cell).
-- system:administrators
+- `system:administrators`
- Users who have privileges to execute some but not all system administrator commands.
-### <a name="2.04 What is an AFS access cont"></a> 2.04 What is an AFS access control list (ACL)?
+### 2.04 What is an AFS access control list (ACL)?
There is an ACL for every directory in AFS. The ACL specifies protection at the directory level (not file level) by listing permissions of users and/or groups to a directory. There is a maximum of 20 entries on an ACL.
For example:
-An AFS ACL is displayed by using the "fs" command as shown below:
+An AFS ACL is displayed by using the `fs` command as shown below:
- tweety@toontown $ fs listacl .
- Access list for . is
- Normal rights:
- fac:coords rlidwka
- system:anyuser rl
+ tweety@toontown $ fs listacl .
+ Access list for . is
+ Normal rights:
+ fac:coords rlidwka
+ system:anyuser rl
-This ACL shows that members of the AFS protection group "fac:coords" have full access rights to the current directory and "system:anyuser" has only read and lookup rights.
+This ACL shows that members of the AFS protection group `fac:coords` have full access rights to the current directory and `system:anyuser` has only read and lookup rights.
-The members of "fac:coords" can be determined by accessing the protection group database using the "pts" command as shown below:
+The members of `fac:coords` can be determined by accessing the protection group database using the `pts` command as shown below:
- tweety@toontown $ pts membership fac:coords
- Members of fac:coords (id: -1577) are:
- sylvester
- roadrunner
- yosemite.sam
+ tweety@toontown $ pts membership fac:coords
+ Members of fac:coords (id: -1577) are:
+ sylvester
+ roadrunner
+ yosemite.sam
-### <a name="2.05 What are the AFS access ri"></a> 2.05 What are the AFS access rights?
+### 2.05 What are the AFS access rights?
In AFS, there are seven access rights that may be set or not set:
-<table border="1" cellpadding="0" cellspacing="0">
+<table border="1">
<tr>
- <th bgcolor="#99CCCC"><strong> lookup </strong></th>
+ <th bgcolor="#99CCCC"><strong>lookup</strong></th>
<td><code>l</code></td>
- <td> Permission to examine the ACL and traverse the directory (needed with most other access rights). Permission to look up filenames in a directory. </td>
+ <td>Permission to examine the ACL and traverse the directory (needed with most other access rights); permission to look up filenames in a directory</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> read </strong></th>
+ <th bgcolor="#99CCCC"><strong>read</strong></th>
<td><code>r</code></td>
- <td> View the contents of files in the directory </td>
+ <td>View the contents of files in the directory</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> insert </strong></th>
+ <th bgcolor="#99CCCC"><strong>insert</strong></th>
<td><code>i</code></td>
- <td> Add new files or sub-directories </td>
+ <td>Add new files or sub-directories</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> write </strong></th>
+ <th bgcolor="#99CCCC"><strong>write</strong></th>
<td><code>w</code></td>
- <td> Modify file contents, use "chmod" </td>
+ <td>Modify file contents, use `chmod`</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> delete </strong></th>
+ <th bgcolor="#99CCCC"><strong>delete</strong></th>
<td><code>d</code></td>
- <td> Remove file(s) in directory </td>
+ <td>Remove file(s) in the directory</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> lock </strong></th>
+ <th bgcolor="#99CCCC"><strong>lock</strong></th>
<td><code>k</code></td>
- <td> Permission for programs to "flock" files in the directory </td>
+ <td>Permission for programs to `flock()` files in the directory</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> administer </strong></th>
+ <th bgcolor="#99CCCC"><strong>administer</strong></th>
<td><code>a</code></td>
- <td> Ability to change the ACL </td>
+ <td>Ability to change the ACL</td>
</tr>
</table>
-There are short-hand forms:
+There are shorthand forms for some common permission combinations:
-<table border="1" cellpadding="0" cellspacing="0">
+<table border="1">
<tr>
- <th bgcolor="#99CCCC"><strong> read </strong></th>
+ <th bgcolor="#99CCCC"><code>read</code></th>
<td><code>rl</code></td>
- <td> read and lookup </td>
+ <td><em>read</em> and <em>lookup</em></td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> write </strong></th>
+ <th bgcolor="#99CCCC"><code>write</code></th>
<td><code>rlidwk</code></td>
- <td> all rights except administer </td>
+ <td>all rights except <em>administer</em></td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> all </strong></th>
+ <th bgcolor="#99CCCC"><code>all</code></th>
<td><code>rlidwka</code></td>
- <td> all rights </td>
+ <td>all rights</td>
</tr>
<tr>
- <th bgcolor="#99CCCC"><strong> none </strong></th>
- <td> </td>
- <td> removes all rights </td>
+ <th bgcolor="#99CCCC"><code>none</code></th>
+ <td></td>
+ <td>removes all rights</td>
</tr>
</table>
-### <a name="2.06 What is pagsh?"></a> 2.06 What is pagsh?
+### 2.06 What is `pagsh`?
A command to get a new shell with a process authentication group (PAG).
-This is normally used if your system does not use the AFS version of login. It is used to get a PAG prior to running klog.
+This is normally used if your system does not get AFS tokens on login. It is used to get a PAG prior to running `klog`/`aklog`.
-The PAG uniquely identifies the user to the Cache Manager. Without a PAG the Cache Manager uses the unix UID to identify a user.
+The PAG uniquely identifies the user to the Cache Manager. Without a PAG, the Cache Manager uses the Unix UID to identify a user and tokens will be shared across all processes owned by that UID.
-### <a name="2.07 Why use a PAG?"></a> 2.07 Why use a PAG?
+### 2.07 Why use a PAG?
There are two reasons:
-1. Child processes inherit the PAG and the Kerberos token so they are AFS authenticated.
+1. Child processes inherit the PAG and the AFS token so they are AFS authenticated.
-1. For security: if you don't have a PAG then the Cache Manager identifies you by unix UID. Another user with root access to the client could su to you and therefore use your token.
+1. For security: if you don't have a PAG, then the Cache Manager identifies you by Unix UID. Another user with `root` access to the client could `su` to you and thereby use your token.
-### <a name="2.08 How can I tell if I have a"></a> 2.08 How can I tell if I have a PAG?
+### 2.08 How can I tell if I have a PAG?
-You can tell if you have a PAG by typing "groups". A PAG is indicated by the appearance of two integers in the list of groups.
+Usually you can tell if you have a PAG by typing `id`. (Platforms which are derived directly from AT&T System V Release 4, such as Solaris, will not show the additional group vector by default; if there is no `groups=` section in the output of `id`, try `id -a`.) A PAG is indicated by the appearance of one or two large integers in the list of groups.
For example:
- sylvester@toontown $ groups
- 33536 32533 staff catz
-
-### <a name="2.09 Can I still run cron jobs"></a><a name="2.09 Can I still run cron jobs "></a> 2.09 Can I still run cron jobs with AFS?
-
-Yes, but remember that in order to fully access files in AFS you have to be AFS authenticated. If your cron job doesn't klog then it only gets system:anyuser access.
-
-The klog command has a "-pipe" option which will read a password from stdin. IF (yes, that's a big if :-) you are prepared to store your password in a local (non-AFS) file then you might use the following:
-
-(a) create a "wrapper" script to get a PAG, get your AFS token and execute a command:
-
- #!/usr/afsws/bin/pagsh
- #
- # NAME afs_wrap_cron
- # AUTHOR Paul Blackburn <mpb@acm.org>
- # PURPOSE Run an AFS authenticated cron job.
- # Get a PAG, get the user's token,
- # then exec user's command
-
- CMD=`basename ${0}`
-
- usage() {
- echo "Usage: ${CMD} [ -principal AFSID ] passwordfile command" >&2
- }
-
- if [ ${1} = "-principal" ]; then
- PRINCIPAL="${1} ${2}"
- shift 2
- fi
-
- if [ -z "${1}" ]; then
- echo "${CMD} error: need name of password file" >&2
- usage
- exit 1
- else
- passwordfile=${1}
- shift
- fi
-
- /usr/afsws/bin/klog ${PRINCIPAL} -pipe < ${passwordfile}
+ sylvester@toontown $ id
+ uid=1000(sylvester) gid=20(staff) groups=33536,32533,20(staff),30(catz)
- if [ -z "${1}" ]; then
- echo "${CMD} error: need name of command to run" >&2
- usage
- exit 1
- else
- command_line="$*"
- command=`echo ${command_line} | awk '{print $1}'`
+On Linux clients, your PAG may not show up as such a group in the group list. An alternative way to check on Linux is to look at your kernel keyring with `keyctl show`:
- # Check if we can run the command.
- # If we got this far, it is likely that the command name is correct
- # but there may be a problem in accessing the command file.
- # If there is an error, log it via syslog (logger) rather than ">&2"
+ $ keyctl show
+ Session Keyring
+ -3 --alswrv 1000 1000 keyring: _ses.32603
+ 819041549 ----s--v 0 0 \_ afs_pag: _pag
- if [ ! -x "${command}" ]; then
- M="error: unable to execute command ${command}"
- logger -i -t "${CMD}" "${M}"
- exit 1
- fi
- fi
- exec ${command_line}
+If you see an `afs_pag` key in the output, then you are in a PAG.
-(b) Store your password in a local (non-AFS) file that only you have access to (perhaps: /home/$USER/.p).
+### 2.09 Can I still run `cron` jobs with AFS?
-Make sure that this file is mode 600 and also be sure that you trust whoever has root access on this system and whoever has access to backup tapes! Also, don't forget to change this file if you change your AFS password.
+Yes, but remember that in order to fully access files in AFS you have to be AFS authenticated. If your `cron` job doesn't `aklog` then it only gets `system:anyuser` access.
-(c) In your crontab file, run afs\_wrap\_cron followed by unlog:
+The preferred way to make use of Kerberos tickets and AFS tokens from a `cron` job is [[kstart|http://www.eyrie.org/~eagle/software/kstart/]]. If you are using the Heimdal implementation of Kerberos, you can also use its `kinit` with the `-afslog` option and a command.
- 0 6 * * * /usr/local/bin/afs_wrap_cron /home/$USER/.p \
- $HOME/bin/6AMdaily; /usr/afsws/bin/unlog
+Note that you can still run a `cron` job without getting a token, if the task does not need to be AFS authenticated. In this case, you may get `stderr` from the `cron` job if your `.profile` is not accessible because of the ACL protecting your `$HOME`. Simply redirect to `/dev/null`:
-Note that you can still run a cron job without getting a token if the task does not need to be AFS authenticated. In this case, you may get stderr from the cron job if your .profile is not accessible because of the ACL protecting your $HOME. Simply redirect to /dev/null:
+ 0 7 * * * $sys_anyuser_readable_dir/7AMdaily 2>/dev/null
- 0 7 * * * $sys_anyuser_readable_dir/7AMdaily 2>/dev/null
+### 2.10 How much disk space does a 1-byte file occupy in AFS?
-### <a name="2.10 How much disk space does a"></a> 2.10 How much disk space does a 1 byte file occupy in AFS?
+This varies depending on the filesystem used by the fileserver containing that file. Some filesystems may only use up 1024 bytes for such a file, and others may use 4096; still others may use more or fewer bytes.
-One kilobyte.
+### 2.11 Is it possible to specify a user who is external to the current AFS cell on an ACL?
-Other filesystems allocate different file block sizes. For example, IBM's AIX version 3 journaled file system (JFS) uses 4K blocks (exception: 2K for the 160MB disk drive).
+Yes. This requires setting up a cross-realm relationship with the Kerberos realm on the remote site, but this is possible. Typically you refer to "remote" users like `user@remote.cell`, and you can use them in ACLs, or add them to `pts` groups.
-Such blocksize differences lead to variations on the amount of disk space required to store files. Copying a directory from AFS to AIX JFS would require more space in JFS because of the block fragmentation.
+### 2.12 Are there any problems printing files in `/afs`?
-Example:
+There are two common issues that come up with printing from AFS:
-(a) Create a one byte file in AFS and use "ls -s" to show how many kilobytes it occupies:
+- the print client passes pathnames to the print service, which does not have access to your AFS token;
- ariel@atlantica $ echo z >/afs/dsea/tmp/one_byte_file
- ariel@atlantica $ ls -s /afs/dsea/tmp/one_byte_file
- 1 /afs/dsea/tmp/one_byte_file
+- if not using a PAG (UID-based tokens), `setuid` print clients don't have access to your AFS token.
-(b) Create same file in local filesystem (AIX JFS):
+Both of these may be mitigated by using shell redirection to send the file to the print client:
- ariel@atlantica $ echo z >/tmp/one_byte_file
- ariel@atlantica $ ls -s /tmp/one_byte_file
- 4 /tmp/one_byte_file
+ lpr < /afs/ny.toontown.com/home/elmer/private/wabbit-hunting
-### <a name="2.11 Is it possible to specify"></a><a name="2.11 Is it possible to specify "></a> 2.11 Is it possible to specify a user who is external to the current AFS cell on an ACL?
+(The `lp` command generally supports the `-c` option to force a file copy. Note that the `lp` command provided with [[CUPS|http://cups.org]] *always* works this way, and makes a connection to the server to transfer the file instead of copying it to a secure queue area directly, so should not have token issues at all.)
-No. You cannot reference a particular user from another AFS cell.
+Very few print services have the ability to manage token access in a way that allows an ACL-protected file to be printed by pathname without enabling access control to be subverted by users by means of the print service. It is **not** recommended to grant the print service general access to AFS by means of [[kstart|http://www.eyrie.org/software/kstart/]] or similar mechanisms.
-You can specify an IP address on the ACL; this means any and all users from the host with that IP address.
+### 2.13 Can I create a FIFO (a/k/a named pipe) in `/afs`?
-Another solution to this problem is to give the external user an "authentication-only" account in your AFS cell. This means that (s)he can klog (but has no home directory) in your cell.
+No. AFS does not support `mknod fifofile p`. AFS only supports normal files, directories, and symlinks; not Unix- or Windows-specific filesystem node types.
- # Example: AFS administrator creates an authentication-only user
- $ uss add daffy "Daffy Duck" -t /dev/null
- $ kas setpassword daffy -admin admin
-
-Cross-realm authentication (where co-operating cells are able to specify remore users as "user@remote.cell" on an ACL) is an **unsupported** feature of AFS 3.3a. That means that Transarc doesn't promise to make it work for you, nor keep it running in future releases.
-
-### <a name="2.12 Are there any problems pri"></a> 2.12 Are there any problems printing files in /afs?
-
-The issue of printing in AFS is almost always the same: what do you send to the printing daemon? Do you send it the bytes you want to print or do you just send the file name containing those bytes? If you send it a file name, you have to be sure that the printing daemon can read it. Most daemons run with no AFS tokens, so can't access directories unless they are open for system:anyuser read access. Often, printing commands (lpr, lp, enq) have an option that allows for both modes of operation, though the default behavior varies from system to system. If you're interested in making your daemons authenticate to AFS, check out the example scripts in AFS-Contrib:
-
-- <file:///afs/transarc.com/public/afs-contrib/tools/reauth-example>
-- <ftp://ftp.transarc.com/pub/afs-contrib/tools/reauth-example/MANIFEST>
-
-Another common problem is setuid printing commands. For instance, the "enq" command runs as root, daemon, or some such user. If you aren't using the AFS login and simply issue "klog" to get tokens, those tokens are associated with your uid. When setuid programs run, they lose access to your token and often can't read the file name given as an argument. The solution in this case is to use "pagsh" before "klog" so that your tokens are transferred to subprocesses automatically by group membership. This works even if the uid changes, as for setuid programs.
-
-### <a name="2.13 Can I create a fifo (aka n"></a> 2.13 Can I create a fifo (aka named pipe) in /afs?
-
-No. AFS does not support "mknod fifofile p".
-
-### <a name="2.14 If an AFS server crashes,"></a><a name="2.14 If an AFS server crashes, "></a> 2.14 If an AFS server crashes, do I have to reboot my AFS client?
+### 2.14 If an AFS server crashes, do I have to reboot my AFS client?
No.
If you are accessing [[ReadWrite]] volumes on a crashed server then you will not be able to save changes back to the server until it returns.
-You don't need to reboot, and the Cache Manager activity is "invisible" to the user.
-
-### <a name="2.15 Can I use AFS on my diskle"></a> 2.15 Can I use AFS on my diskless workstation?
+You don't need to reboot, and the Cache Manager activity is "invisible" to the user. You may want to speed up recovery by issuing the command `fs checkservers`, but even this is unnecessary and will usually only improve recovery by a few seconds.
-Yes. The AFS Cache Manager can be configured to work with either a disk based cache or a memory (RAM) based cache. With the latter, you can expect file access from the cache with a whizz!
+### 2.15 Can I use AFS on my diskless workstation?
-<http://www.uni-hohenheim.de/~schaefer/afs/info-afs/1306.html>
+Yes. The AFS Cache Manager can be configured to work with either a disk based cache or a memory (RAM) based cache.
-### <a name="2.16 Can I test for AFS tokens"></a><a name="2.16 Can I test for AFS tokens "></a> 2.16 Can I test for AFS tokens from within my program?
+Note that using a memory cache may not be as fast as you might think. Modern operating systems should cache disk data in memory when accessed, so using a disk cache should mean you are hitting RAM most of the time anyway. Disk caches are also much more common, and thus much more heavily tested, and so are better optimized. If you have a local disk and it's reasonably fast, usually going with a disk cache is preferable to memory cache. Additionally, most operating systems do a better job of optimizing a native RAM disk, so you might consider putting your AFS cache in a RAM disk instead of using [[OpenAFS]]'s own memory cache.
-Yes. Some sample code showing how to do this can be found in:
+### 2.16 Can I test for AFS tokens from within my program?
-<file:///afs/transarc.com/public/afs-contrib/tools/auth-samples/listtokens.c> <ftp://ftp.transarc.com/pub/afs-contrib/tools/auth-samples/listtokens.c>
+Yes. However, the mechanism for doing so varies depending on the platform. To see examples of how to do this, you can look at the source of any program that deals with AFS tokens. One such example is [pam-afs-session](http://www.eyrie.org/~eagle/software/pam-afs-session/)
-### <a name="2.17 What's the difference betw"></a> 2.17 What's the difference between /afs/cellname and /afs/.cellname?
+### 2.17 What's the difference between `/afs/cellname` and `/afs/.cellname`?
AFS has [[ReadOnly]] (RO) and [[ReadWrite]] (RW) volumes.
-The convention in AFS is to mount the RW volume "root.cell" as /afs/.cellname and the RO volume "root.cell.readonly" as /afs/cellname.
+The convention in AFS is to mount the RW volume `root.cell` as `/afs/.cellname` and the RO volume `root.cell.readonly` as `/afs/cellname`. This is so that when you travel down the `/afs/.cellname` link, AFS will always use the RW site of any volumes that have RO clones. This allows your administrator to update the RW copy of a volume and `vos release $volname` so that it will appear in `/afs/cellname`.
-This is so that when you travel down the /afs/.cellname link, AFS will always use the RW site of any volumes that have RO clones.
+### 2.18 Can I `aklog` as two users on a machine in the same cell?
-This allows your administrator to update the RW copy of a volume and "vos release $volname" so that it will appear in /afs/cellname.
+Yes, *if* you use two different PAGs. The token store only supports one token per cell per authentication group; with UID-based PAGs, this means one token per cell per user, but with PAGs you can have multiple shell windows/sessions, each with its own PAG and associated AFS tokens.
-### <a name="2.18 Can I klog as two users on"></a> 2.18 Can I klog as two users on a machine in the same cell?
+Note that most Kerberos implementations (the one on Mac OS X 10.7 and 10.8 being a notable exception) only allow a ticket-granting ticket (TGT) for a single principal (this restriction is even tighter than AFS's, as you cannot have a separate TGT per realm!), so if you plan to use separate PAGs you will also want to use separate credential caches ("ticket files" in older Kerberos parlance).
-Yes, if you use two different PAGs.
+An alternative to using multiple users in this way is to use ACLs to grant access on a shared directory to both users.
-It's: "One token per PAG per client system."
-
-From one shell you can only authenticate as a single user of a cell. If you open another shell (with another PAG) you can klog as a different user of the same cell from the same client.
-
-You can authenticate into many cells from one client shell.
-
-### <a name="2.19 What are the ~/._afsXXXX f"></a> 2.19 What are the ~/.\_\_afsXXXX files?
+### 2.19 What are the `~/.__afsXXXX` files?
They are temporary reference files used by the AFS Cache Manager.
-In UNIX filesystems, when you a remove a file that is kept open by a process, the file stays around physically while it is no longer referenced in any directory (which you will see as a mismatch between disk space usage according to df and du).
+With most Unix filesystems, when you a remove a file that is kept open by a process, the file stays around physically while it is no longer referenced in any directory (which you will see as a mismatch between disk space usage according to `df` and `du`).
-Some applications rely on that feature, e.g. they create a temporary file and remove it immediatley while keeping the file descriptor open. The file then disappears from the filesystem automagically when the process terminates or the file descriptor gets closed otherwise. Such applications could get into trouble with older versions of AFS, where the file could really disappear while it was held open.
+Some applications rely on that feature, e.g. they create a temporary file and remove it immediatley while keeping the file descriptor open. The file then disappears from the filesystem automatically when the process terminates or the file descriptor gets closed otherwise. Such applications could get into trouble with older versions of AFS, where the file could really disappear while it was held open.
-Newer versions of AFS rename such files to .\_\_afsXXXX, thus making sure that the data stays around as expected by the application. As soon as the file gets closed, the associated .\_\_afsXXXX should disappear.
+Newer versions of AFS rename such files to `.__afsXXXX`, thus making sure that the data stays around as expected by the application. As soon as the file gets closed, the associated `.__afsXXXX` should disappear.
-### <a name="2.20 How do you set up IP-based"></a> 2.20 How do you set up IP-based ACLs?
+### 2.20 How do you set up IP-based ACLs?
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?
+### 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.
+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.
+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
+ - 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, `0400` octal) 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 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, `0200` octal) bit is set
- you are the owner of the file
- - you are a member of system:administrators
+ - 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 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 the 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.
+The "sticky" bit, group of a file, `g+rwx` (octal `0070`), and `o+rwx` (octal `0007`) bits are completely ignored by all AFS components. Additionally, the `u+rwx` (octal `0700`) 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.
+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"?
+### 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.
+When the ACL on a directory is set to `irl` (_read_, _list_, _insert_), 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.
-
-### <a name="2.23 Can I access a RW-Volume"></a>2.23 Can I access a RW-Volume using the RO-Path ?
-
-Depends. Once, you have RO-Volumes released, a mountpoint pointing to the RO, will bring you to the RO-Volume.<br/>
-To change that behaviour, you have to change the corresponding mountpoint.<br/>
-However, for some situations, like software installations, it might be useful to
-reach the RW-Volume through the RO-path.<br/>
-
-You can do that for a single client with a special setup. <br/>
+Also, note that a `system:anyuser irl` ACL has an 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.
-The trick is to break the convention described in 2.17 for a single client : <br/>
-You mount the RW volume "root.cell" as /afs/cellname. <br/>
+### 2.23 Can I access a RW volume using the RO path?
-This can be done by creating an alternative "root.afsrw" - Volume ( in contrast to root.afs),
-where you do the RW-mount.<br/>
-Then you must not use on this special client the "dynroot" -option and use this alternative root.afsrw
-as root volume, by adding "-rootvol root.afsrw" to the afsd commandline-options on startup.
+Depends. Once you have RO-Volumes released, a mountpoint pointing to the RO will bring you to the RO volume. To change that behavior, you have to change the corresponding mountpoint with `fs rmmount` and `fs mkmount -rw`. However, for some situations, like software installations, it might be useful to reach the RW volume through the RO path.
-
+You can do that for a single client with a special setup. The trick is to break the convention described in 2.17 for a single client: mount the RW volume `root.cell` (instead of `root.cell.readonly`) as `/afs/cellname`. This can be done by creating an alternative `root.afsrw` volume which is identical to `root.afs` except that it has an RW mount for `root.cell`, then add `-rootvol root.afsrw` to the `afsd` command options on startup (either in `/etc/init.d/afs` or wherever your system stores service configuation; this is often `/usr/vice/etc/config/afsd.options` on most Unixes and `/etc/sysconfig/afs` on many Linux distributions) and ensure that the `-dynroot` option is *not* specified.
git://git.openafs.org / openafs-wiki.git / blobdiff