[OpenAFS-devel] Re: [kerberos-discuss] Solaris 10 SSHD, pam_krb5 and xscreensaver handling of renewed/forwarded ticket

[Douglas E. Engert]

Shawn M Emery wrote:
> Henry B. Hotz wrote:
>> On Nov 8, 2007, at 8:30 AM, Douglas E. Engert wrote:
>>
>>  
>>> Thanks for the response, and so some of my comments below.
>>>     
>>
>> I'll second Doug's concerns:
>>
>> 1) Should save the new tgt even if the old one isn't expired.  I  
>> expect ancillary service tickets to be erased and for applications  
>> that need them to be smart enough to reacquire them if needed.  (AFS  
>> usually isn't, but it has a separate credential store so it's service  
>> ticket usually isn't erased either.  Wish it did auto-acquire, but  
>> that's another subject.)
>>   
> 
> I'll review the applications (at least w/in the Solaris OE) to see if 
> they are not impacted negatively from this.  Can you think of any other 
> 3rd party applications that would be? 

No. The normal mod of operation for Kerberos has always been kinit gets TGT
and destroys any tickets. All applications have had to deal with this situation
I could not think of any application that expects its service ticket to
be present in the cache. If it did it would have had to have some helper
routine get it ahead of time.

> If the list is long then it would 
> be preferred to preserve the old behavior and to allow the new.
> 
>> 2) Ticket stores should be per-session.
>>   
> 
> Yes, but I think there should also be a way of acquiring a TGT from 
> outside of the session.  For example; processes that are long running or 
> delayed execution could use credentials acquired from another mechanism, 
> such as from password authentication or delegation. 

Agreeded. At the applicaiton level, the KRB5CCNAME can be used to
point at a ticket cache. But at the Kernel level the env in not available,
and a way needs to be found around this. It can be done, DCE knew how to
name the cache with a number known to the kernel, and the dced could use
this to access the cache for the kernel much like I believe your gssd does.

This might be a little off the discussions but another way to look at
the situation is Unix is still held hostage to the UID. The UID *IS the*
credential for access to the local file systems. Possession of the credential
and verification of the credential is done by the kernel, that is also the
resource manager for the local file system. But the kernel could use other
credentials (Kerberos tickets) that are not tied to a UID if the file system
(or resource manager) could also use them.  This is what AFS and (I beleive)
NFSv4 with Kerberos can do, as well as web servers, databases and other
applications not tied to local file systems.

> 
> Shawn.
> -- 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444