[OpenAFS] Cron jobs without service keytab

Lukas Kubin kubin@opf.slu.cz
Tue, 13 Apr 2004 16:45:36 +0200

This is a cryptographically signed message in MIME format.

Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mark Montague wrote:
> 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
>>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.

Thank you. I started this thread to ensure myself I'm not missing any 
existing way how to deal with cron jobs in AFS-based network. After your 
exhaustive description I'm quite sure what options do I really have :-)

Thank you all a lot.


Lukas Kubin

phone: +420596398275
email: kubin@opf.slu.cz

Information centre
The School of Business Administration in Karvina
Silesian University in Opava
Czech Republic

Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature