[OpenAFS] Cron jobs without service keytab
Tue, 13 Apr 2004 10:10:39 -0400 (EDT)
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
kinit -k -t /path/to/keytab username/cron@REALMNAME
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.
LS&A Information Technology
The University of Michigan