As hinted before, a password must be present to obtain any Kerberos identity. However, that password may come either from an interactive terminal, or from a file. (A file that is residing outside of the AFS space, of course!).
Kerberos discourages exporting of actual password keys into files, so at HCoop we create two Kerberos "identities" for each user: one named USER (your Unix username) for interactive sessions, and the other named USER.daemon for unattended sessions.
- Your USER principal has the password saved only in the protected Kerberos database and it is not possible to obtain its ticket without providing the password.
Your USER.daemon principal has a very long random secret assigned to it and its key exported to a file named /etc/keytabs/user.daemon/USER. Your scripts will use the file /etc/keytabs/user.daemon/USER as a password in obtaining Kerberos/AFS identity "USER.daemon". In fact, all shared HCoop daemons also use that file to obtain permissions to write into your home directory (such as to deliver mail). Of course, Unix permissions and ownership on the keytab file are such that no other user can read your keytab file.
Token "scope"
Kerberos and AFS introduce a concept called Process Authentication Group ("PAG").
If you obtain the Kerberos ticket and AFS token within the PAG, the tokens will apply only to the current process (usually a shell) and the processes started from it (its children).
If you obtain the Kerberos ticket and AFS token outside the PAG, the tokens will apply to all processes running under your Unix username (well, to those that are not members of some existing PAGs, of course).
To "enter" a PAG, you start shell named /usr/bin/pagsh.openafs. With SSH, even though you find yourself in the shell of preference, a PAG is created for you just beforehand. (Verify by running id and noticing one numerical, untranslated entry such as 1105575254). Once within a PAG, there is basically no way to "escape" from it, so in effect, it is not possible to affect Kerberos/AFS identity of any of your other running processes by SSH-ing into a machine and doing kinit as a different principal or obtaining different AFS tokens - they only apply to your current shell and its subprocesses.
In contrast, when unattended processes are started in your name, they are free of a PAG so you have the freedom of choice - influencing all "pagless" processes running under your Unix username, or starting pagsh manually and restricting influence to the current process and its children.
This quickly leads to two possible strategies:
- Have one pagless process running which is refreshing USER.daemon token periodically (to keep it from expiring), and also run all scripts pagless - they will automatically find themselves to have that USER.daemon token.
Invoke all your scripts with shell /usr/bin/pagsh.openafs (can be in the #! "shebang" line) and obtain AFS token immediately after. Then rely on all subprocesses started from that script to inherit the obtained identity.
Unattended Access Privileges
In any case, using file /etc/keytabs/user.daemon/USER to obtain your Kerberos/AFS identity will "log you in" into AFS as USER.daemon, not USER. Therefore, make sure that all directories you want to access from unattended scripts have read or write permission for USER.daemon in addition to USER.
For example, here's how the permissions look for your ~/Maildir/ which gives USER.daemon write access:
$ fs la ~/Maildir/ Access list for /afs/hcoop.net/user/U/US/USER/Maildir/ is Normal rights: system:administrators rlidwka USER rlidwka USER.daemon rlidwka
To give read permission on a directory, use
fs sa DIRECTORY USER.daemon read
To give write permission on a directory, use
fs sa DIRECTORY USER.daemon write
To recursively give write permission for all subdirectories,
find DIRECTORY -type d -exec fs sa {} ${USER}.daemon write \;Note that we mention directory permissions only - in AFS, there are no file permissions. Directory permissions apply to all contained files, except subdirectories. Each subdirectory defines its own permissions. When new subdirectories are created, they inherit the ACL list from the parent directory. If you want to change ACLs on an existing directory tree, just use the fsr command in place of fs, with the same arguments.