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

Henry B. Hotz hotz@jpl.nasa.gov
Wed, 14 Nov 2007 09:32:05 -0800


On Nov 14, 2007, at 6:33 AM, will young wrote:

> Shawn M Emery wrote:
>> Henry B. Hotz wrote:
>>> On Nov 8, 2007, at 8:30 AM, Douglas E. Engert wrote:
>
>>> 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.
> 	I haven't looked recently but in general there have not been  
> cohesive sessions to tie processes (and kernel actions) to unless  
> auditing is enabled.
> 	-Will

All of us seem to have interpreted this comment differently, or at  
least to have very different concerns related to it.

My concern when I wrote that is that the credential cache for a  
console login should be independent from the one for an ssh session  
(and each ssh session should be independent from the others)  
*even*if* they are for the same nominal user and UID.  Maybe I want  
my credentials erased when I logout, but I don't want the ssh session  
killed when I log out from the console.  If you're not concerned with  
actual secure isolation this could be as simple as a per-session CC  
name.  I'd *like* something akin to an AFS PAG with actual secure  
isolation as well, but I know that's hard.

Maybe network identities are independent of local UID and there's  
just no correspondence at all.

One use case we have here is an operator console for e.g. a testbed.   
It runs continuously, and nobody *ever* logs the console out.  OTOH  
the person in front of the console changes every 8 hours.  I've been  
advocating that the operator do a kinit/klog at shift change.  Then  
network operations and logs can be traced to the real person on duty,  
but you don't have to kill/restart all the monitoring processes.   
Making this work right goes to my first point as well, of course.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu