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 <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
