This is the chapter of the MemberManual that describes how to periodically run unattended commands using cron.

TableOfContents

Introduction

All users' home directories in HCoop setup are located on AFS partitions. The use of AFS implies the use of Kerberos. In essence, your Kerberos (and AFS) "identity" is completely unrelated to your Unix username. While you do automatically obtain Kerberos and AFS identity (so-called "tokens") when you log-in to HCoop machines over ssh, be aware that Unix and Kerberos/AFS login are two separate things. That's why the scripts you run unattended cannot write (or read) files because, without extra steps taken, they do not have any useful identity or access privileges to partitions where all the relevant data is residing.

So, in general, when you want to access AFS space (that means any file in your home directory), you first need to authenticate with Kerberos to obtain a valid TGT ("Ticket-granting ticket"). As the name implies, the TG Ticket is then used in automatically obtaining futher tickets for access to specific services (such as to ssh, ftp, bugzilla, members portal or AFS on any of the servers in the HCoop administration "realm").

For a quick... see MemberManual/UsingCron/QuickStart.

The AFS "Login" Process

Following the above, here's the complete, "expanded" series of events that take place in a typical remote shell session:

1. You log in by providing your Unix username and password

2. You authenticate to Kerberos and obtain the TGT by running kinit. (Verify with klist -5).

3. You use the TGT to obtain AFS "token" by running aklog. (Verify with tokens).

4. You access files in the AFS space. Actual access privileges are determined by the combination of the token you are holding and the access control lists (ACLs) set on a directory. (List access rules with fs la DIRECTORY).

Interactive SSH process

Our SSH service is configured in such a way that your password is, in fact, the secret Kerberos key. So when you log in over SSH, steps 1 to 3 above are performed for you automatically and you can use AFS right away.

Non-interactive (Unattended) Processes

When a script is started in your Unix name by Cron, At or any other delayed/controlled-execution facility, no Kerberos ticket (or AFS token) is obtained automatically. Part of the reason lies in the fact that Kerberos' security model makes it almost impossible - even for root users - to authenticate as yourself if the password is not provided. (Where in Unix we would use "sudo" to easily impersonate any user, here it is impossible).

So the way to obtain Kerberos ticket and AFS token from unattended processes will be explained.

Ways of Obtaining AFS Tokens from Unattended Scripts

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.

1. 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.

2. 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).

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 kinitting 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.