[kerberos-discuss] Kerberos CCAPI [PSARC/2009/030 FastTrack timeout 01/22/2009]

[Douglas E. Engert]

Shawn M Emery wrote:
> 
> Changing kerberos-interest at sun.com to kerberos-discuss at opensolaris.org ...
> 
> Nicolas Williams wrote:
>> On Tue, Jan 20, 2009 at 01:28:22AM -0700, Shawn M Emery wrote:
>>   
>>> Nicolas Williams wrote:
>>>     
>>>> If such a mechanism is missing then this case seems incomplete.
>>>>  
>>>>       
>>> I purposely left the session naming mechanism out of the one-pager, as I 
>>> believe something more systemic needs to thought out and deserves it's 
>>> own case and transcends anything in CCAPI's scope.
>>>     
>>
>> Then as long as this case retains the words "per-session" it will be
>> incomplete.
>>
>> Either remove those words, add the missing facility, or block on a
>> future case that should provide it.
>>   
> 
> I purposely specified "will allow", "support", and "helpful" in regards 
> to sessions.  As the applications still have an interface for designing 
> specific forms of session.  If the scope of the project is to define a 
> system level or SPI then I believe that this warrants a separate case as 
> it impacts many applications and not necessarily specific to Kerberos.
> 
>>> My primary reasoning of having the CCAPI is the ability to have multiple 
>>> default credentials for purpose of separating initial login credentials 
>>> and those required for long running and delayed execution processes.  To 
>>> this purpose all that would be required is two forms of cache naming 
>>> those of delayed execution and those of initial login.  To me this is an 
>>> implementation detail.
>>>   

I wish you would try and make this more generic, and allow multiple credentials,
and not just for delayed execution. There are times when a user may which to
switch to using a different principal to access a file system for example, or when
a user su's to root but keeps access to the same network file access.

(We use session based cache names with sshd at least, and AFS for a shared
network file system, that is capable of using the different caches.)

>>
>> Without a kernel-side hook these credentials will not be available for
>> secure NFS on a per-session basis.  Therefore this is insufficient and
>> incomplete.
>>   

Yes the issue alway seams to come back to gssd can't do it, so it can't be done.
AFS and DCE used PAGs, and DCE would use the PAG number as part of
a cache name, so it can be done in the kernel.

> 
> Currently, gssd uses the principal to map to the local user.  I believe 
> that this is still useful and could be used in order to lookup a special 
> CCAPI entry and to fall-back to file stores created by initial login.

You really need to get away form relying on UID for the mapping and look at PAGs,
keyrings, or some other method to use instead of UID to identify credentials.

IMHO, possession of a UID by the kernel for a process is in effect a credential.
But the credential is is only good for file systems controlled by the kernel.
So a process with a UID may want to also possess other credential too
for access to other file systems independent of the UID, and doing a
su command in effect is changing only the UID credential, not necessarily
other credentials used to access other file systems.

> 
>>>> Where are the door handles for CCAPI daemons fattach()ed?
>>>>
>>>> How are these daemons started?
>>>>
>>>> For example, gssd using doors should be started by svc.startd, not
>>>> inetd.  So there's at least one architectural change that probably needs
>>>> to be described (but maybe not -- is the restarter for a service an
>>>> architectural detail?).
>>>>       
>>> Yes, as it affects the FMRI, but I haven't done away with gssd yet :)
>>>     
>>
>> Why should the FMRI change?
>>   
> 
> If gssd goes away then the FMRI goes from being defined to that which is 
> not :)
> 
>>>> How are the CCAPI daemons started?  Are they started by pam_krb5(5)?
>>>> By kinit(1)?  By an IPC call from either pam_krb5(5) or kinit(1) to a
>>>> master CCAPI daemon started by SMF?
>>>>
>>>> And how are these daemons reaped?  For login sessions [where pam_krb5 is
>>>> involved[ I'd expect that pam_krb5:pam_sm_close_session() takes care of
>>>> it.  But if new CCAPI daemon processes can be started by kinit, then how
>>>> are they destroyed?
>>>>       
>>> To me these are all implementation details that I purposely did not 
>>> cover in the requirements details.  But in any case, here are 
>>> implementation details, for the curious:
>>>
>>> http://k5wiki.kerberos.org/wiki/Projects/CCAPI_for_UNIX
>>>
>>> under "Spawning new server and connecting".
>>>     
>>
>> That has implementation details, but strongly implies a UI and/or API.
>> Those missing interfaces need to be described.  (Surely the protocol
>> described in the linked page is not intended for _users_ to execute
>> through netcat or some such, right?)
>>   
> 
> Hmmm, locking down specific things like timing on process reaping might 
> paint oneself in the corner in a requirements document.
> 
>>> Additional advice given is that the ccache server should exit after 
>>> inactivity, therefore store the ccache encrypted on disk.
>>>     
>>
>> How will the daemon know when no long-running processes require it any
>> longer?
>>   
> 
> Not to paint myself in corner, x minutes.
> 
>>> I think any further implementation details can be taken off list.  I'm 
>>> just trying to get requirements approval at this point, as I certainly 
>>> don't want to paint myself in the corner on an implementation detail 
>>> that I discover later on is not the most efficient/reasonable design :)
>>>     
>>
>> I believe this case is incomplete as it stands.  Were I an ARC member
>> I'd ask you to address these issues and update the materials, else
>> derail.  I hope an ARC member does as much.
>>   
> 
> I certainly think that the session id SPI is a much needed project, 
> however I don't think that it should be lumped into the CCAPI project.  
> I can't decide on my own that CCAPI would block on a session id project, 
> but I will certainly argue on both sides.
> 
> Shawn.
> --
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> kerberos-discuss mailing list
> kerberos-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss

-- 

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