cron on AFS files]

[Ken Hornstein]

>>You certainly have the ability to dictate the contents of /usr/vice/etc/
>>CellServDB on your AFS clients, don't you? :-)
>
>That'd be pushing it :-)
>
>I suppose if we'd thought of it when we started deploying clients five 
>years ago we could have done it, at the expense of having to work with 
>people who actually did have and wanted to use a krb.conf for their own 
>purposes.  Too late now to make it work reliably, and it has to be reliable.

But I think if you make the conditions for using this program, "You have
to have a krb.conf with these entries in it", then people who wanted
to use this program would be highly motivated to fix it.

>I'm aware of this routine, we even use it, but the documentation is 
>thoroughly inadequate to understanding it (all I have is 
>/afs/transarc.com/public/afsps/doc/progref/3.0/main.ps, anyway).  Does that 
>do failover?  But in any case, it takes a password, and for improving 
>gettoken, I need something that takes a key.

Geez ... you've got the source, Pete! :-)

>From looking at the source to ka_UserAuthenticateGeneral, I think you
need to call ka_GetAuthToken and ka_GetAFSTicket (look at GetTickets in
kauth/user.c).

>> >>The advantage of gettoken is that it uses a srvtab and not a user
>> >>password.  The srvtab still needs to be stored somewhere on the local
>> >>machine, and is a security issue, but it's not quite as bad as
>> >>storing a naked plaintext password.
>>
>>I don't really agree here; it's only _slightly_ better (I'm talking a
>>hair better), since the key is a password-equivalant.
>
>Sure, but do you have a better idea?

Oh, please don't understand me; I think this is a reasonable idea, _as
long as you understand the limitations and vulnerabilities_.  We do
this here as well.  But telling people that storing a key isn't as bad
as a password is doing them a disservice, IMHO.

In case you're wondering .... for users that want this at our site, we
give them a special "cron" instance (kenh/cron in V5 format, kenh.cron in
V4 format) and let the user add the cron instance to the appropriate ACLs
in AFS.  Since that special cron user has restricted priviledges (they
can't use it for interactive login by default), I'm confortable with
that tradeoff.  But since we use Kerberos 5 with AFS, we use Kerberos 5
tools for that, so that won't help you.

--Ken