Authenticating Daemons to AFS

In normal situations, daemons that are (for example) run as background processes, do not have authenticated access to AFS. This page describes a mechanism for running background daemons so that they can obtain such access. We recommend you have a working knowledge of AFS before proceeding.

You can visit our main AFS page for general AFS in information. We also recommend reading our knowledge article on AFS Cache Manager and Authentication.

Please note that the procedures described here are for hosts built by SCS Computing Facilities (Dragon).

How to do it

The basic procedure for running authenticated daemons involves the following steps (1 and 2 are setup steps that should only have to be done once):

1. Create, key and define the username.daemon Kerberos instance
2. Add the username.daemon instance to AFS ACLs as necessary
3. Run the daemon so that it gets its own PAG, Kerberos ticket and AFS tokens

Before you begin, you may wish to back up any existing username.daemon.* files in your present working directory.

Create, key and define the username.daemon Kerberos instance

• Use the klist command to confirm you have current tickets for your null instance
• Change to a non-AFS, non-public directory
• Run the following commands:
  • (umask 077; remctl kerberos instance keytab ${USER}/daemon > ${USER}.daemon.keytab)
  • remctl afs pts createuser ${USER}.daemon
• As root, move the resulting .keytab file to /etc/not-backed-up/

Add the username.daemon instance to AFS ACLs as necessary

To minimize any potential security risks, you should only add this instance to the ACLs of directories that the daemon needs to access. See the AFS Permissions page for instructions on how to change ACLs.

Running the daemon

The specific steps for running the daemon vary depending on whether you are per ing these steps on a host running Fedora or Ubuntu. Please use the steps indicated for your platform :

Ubuntu

You can use kinit or kstart to run the daemon depending on how long your daemon or process takes to run:

Use kinit

If the daemon or process you are running completes in an amount of time shorter than the default ticket lifetime (typically 24 hours), you should use kinit. You can run the daemon with a crontab entry like:

kinit -kt /etc/not-backed-up/${USER}.daemon.keytab example/daemon /path/to/script

Use kstart

If the daemon or process you are running will take longer than the default ticket lifetime (typically 24 hours), you should use kstart. Please note that kstart is not available by default but is available for installation via apt-get. You can run the daemon with a crontab entry like:

/usr/bin/k5start -t -f /etc/not-backed-up/${USER}.daemon.keytab -K 60 ${USER}/daemon /path/to/script

The -K 60 switch specifies a time in minutes for the tickets for tickets to be renewed beyond the default ticket lifetime.

Fedora

It is important that the daemon is run in a way that it gets its own PAG before starting. If it does not do so, all processes without a PAG with the same Unix user ID as the daemon will share the same token and perhaps have undesired authenticated access to AFS. The general procedure to follow is:

1. Before starting the daemon:
   • Get a new PAG.
   • Set unique names for KRBTKFILE and KRB5CCNAME in the process environment.
   • Obtain the Kerberos tickets, including an AFS service ticket and store the AFS token.
2. Now execute the daemon.
   • At this point, the daemon will inherit the Kerberos tickets (via the KRBTKFILE and KRB5CCNAME in the environment) and the AFS tokens (via the PAG which is shared by all descendants of the PAG creator).
3. After the daemon is running:
   • Have some mechanism to periodically renew tickets before they expire (the default ticket lifetime is usually 25 hours).
   • Have some mechanism to detect when the daemon has exited, either via looking for a /var/run/<daemon>.pid file or through some other means.

As long as the process that is maintaining the tickets has the same PAG and the same KRBTKFILE and KRB5CCNAME then tickets for the daemon process can be maintained forever.

The following wrapper Perl script is an example of how to do the above steps: run_with_tickets

Before using this script, you should read through it and modify variables appropriately for your application. This script has not been extensively tested.

The sample "run_with_tickets" script uses a child watcher process to maintain the tickets. It exits when it detects that its parent process is gone. The parent process is assumed to be the daemon (or some indefinitely running process) which is exec-ed to replace the parent Perl process.

It is common for daemon processes to use a paradigm where the daemon will fork, the parent will exit, and the child will continue execution thus placing itself in the background. Such daemon processes must be started with a switch so that the daemon does not per this forking operation.

If the daemon does not support startup without placing itself in the background, then you will need maintain your own script using the above guidelines.

If the daemon does support the "run_with_tickets" script, then you can start your daemon with a "launch_daemon" script that contains the following:

 /usr/mypkg/etc/run_with_tickets /usr/mkpkg/bin/my_daemon arg1 arg2 >/some/log/file 2>&1 &

The above example assumes a sh-based script with associated files located under "/usr/mypkg"