[OpenAFS] Cron jobs without service keytab

[Mark Montague]

On Tue, 13 Apr 2004, Lukas Kubin wrote:

> > No.  Why don't you want to use keytabs?  I'm not saying "you should
> > use keytabs" but if you can tell me why you do not want to use them,
> > I might be able to suggest another solution that would satisfy your
> > requirements.
>
> Sure. The reason is I wish the common users to work with the AFS system
> just like with any other common Linux system both on a multiuser
> application server and their workstations in campus.
> It would bring more administrative work to create and manage such
> specific principals. Also I would have to treat such principals like
> they were another users in our system - ie. I have to create additional
> LDAP, pts entries, set up their ACLs etc.

I don't think that what you want is possible.  The reason is that,
unlike most deploments of NFS, AFS servers do not trust the AFS
clients to say who users are -- users have to prove their identities
to the server in order to access their AFS files.  This is an
intentional feature of AFS -- some degree of transparancy and
ease of use was given up in favor of security, which is necessary
if AFS was to be a world-wide highly distributed networked filesystem.

Your options here include:

    - For each user who wants to run a cron job that needs to
      access protected files in AFS, set up an additional
      Kerberos principal and PTS entry for them.  The Kerberos
      principal would be username/cron@REALMNAME and the PTS
      principal would be username.cron   You then create a keytab
      for username/cron@REALMNAME which you put on the machine
      that runs the cron job and permit so that only the user can
      read it.  You then grant the appropriate AFS filesystem
      rights to username.cron using the "fs setacl" command so
      that a script running with a token obtained from the keytab
      can read and/or write to the necessary files in the
      user's home directory.  You then tell the user that the
      first thing their cron job needs to do is get a token.
      Russ posted a URL last week to a web page containing some
      scripts that might be useful for this, or you can use
      the commands:
            kinit -k -t /path/to/keytab username/cron@REALMNAME
            aklog
      This is an additional hassle to set up, but it is in
      exchange for real security -- when set up properly, AFS
      will protect both the user's identity and their data.
      Hopefully, most users won't need to run cron jobs.  Of
      those users who do need to run cron jobs, many cron jobs
      might be able to run with just system:anyuser access to
      things in AFS (for example, many cron jobs could be written
      to use a temporary data directory on the local machine).
      So hopefully, you won't need to set up any keytabs.

    - An alternative option is to set up cron to acquire a
      token for users.  Note that this would be a Kerberos
      principal of the form machinename/cron@REALMNAME with
      a corresponding PTS entry of machinename.cron.  All users
      who ran cron jobs would get the same token.  This has
      the downside that if one user grants machinename.cron
      write access to a subdirectory in their home directory,
      all other users cronjobs will have write access to this
      subdirectory, too.  This is less secure and less flexible
      than the first option above, and, depending on your system,
      you may need to make changes to your cron daemon startup
      script, your PAM configuration, your PAM modules, and/or
      changes to the cron daemon source code.

Here at the College of Literature, Science, and the Arts at
the University of Michigan, we use the first option above.

AFS comes with more administrative overhead than other filesystems,
but it also has more features and better security.  My opinion
is that the administrative overhead is reasonable and worth the
benefits that it brings.

If your requirements are to have something that the users do not
have to do anything special for, ever, then NFS is closer to
meeting your need.  Note, however, that you'll be giving up a
lot of the features and security that AFS has.  Also note that
some versions of NFS support Kerberos, and in these cases, if
you use the Kerberos support in NFS, you'll have the same sorts
of problems that you are currently having with AFS.

Sorry I can't provide the answer you were looking for.

                Mark Montague
                LS&A Information Technology
                The University of Michigan
                markmont@umich.edu