On Tue, Oct 13, 2009 at 11:44 AM, Jeff Layton <[email protected]> wrot=
e:
> On Tue, 13 Oct 2009 08:28:52 -0700
> raini-9HxftnAiGddWk0Htik3J/[email protected] wrote:
>
>> Jeff Layton <[email protected]> said:
>> >> Just to be clear - you mean doable to a coder who might like to i=
mprove
>> >> on
>> >> gssd/kernel credential separation, rather than a non-coding sysad=
min who
>> >> needs with work within the current NFS/gssd framework?
>> >>
>> >
>> > Correct, that's what I mean. It'll mean modifying kernel and rpc.g=
ssd
>> > code.
>>
>> Thanks for confirming. =A0Skipping back a little:
>>
>> >> > No, gssd (the client side daemon) will search /tmp for anything=
that
>> >> > looks like a credcache for the right user, verify that it is a
>> >> > credcache and then pick the one with the latest TGT expiration.
>>
>> Kevin Coffman on the NFS4 list actually implied this used simple mti=
me
>> rather than actually scanning /tmp/krb5cc_uid* for ccache files with=
the
>> latest TGT expiration, which is how I originally read your statement=
=2E
>> This seemingly would make a difference in an environment with a batc=
h job
>> with a long lifetime ticket and subsequent interactive login generat=
ing a
>> separate ccache file with a shorter lifetime but newer mtime.
>>
>> I'm not a coder but I scanned krb5_util.c in the gssd code, and it *=
seems*
>> to me it only looks at mtime, although what you suggest would be mor=
e
>> optimal. =A0Could you confirm whether it's scanning ccache files for=
longest
>> TGT, or just using mtime?
>>
>
> You and Kevin are correct. rpc.gssd only looks at the mtime. When I d=
id
> the work to allow the CIFS SPNGEO upcall to find alternate credcaches=
,
> I implemented the behavior I described (prefer the latest TGT
> expiration) -- sorry for the confusion...
>
> It probably wouldn't be too hard to change rpc.gssd to prefer
> credcaches with the latest TGT expiration if it was considered a
> desirable change.
>
> Kevin, any thoughts?
I agree it shouldn't be too hard to change if that behavior is desirabl=
e/useful.
On Tue, 2009-10-13 at 11:51 -0400, Kevin Coffman wrote:
> On Tue, Oct 13, 2009 at 11:44 AM, Jeff Layton <[email protected]> wrote:
> > On Tue, 13 Oct 2009 08:28:52 -0700
> > [email protected] wrote:
> >
> >> Jeff Layton <[email protected]> said:
> >> >> Just to be clear - you mean doable to a coder who might like to improve
> >> >> on
> >> >> gssd/kernel credential separation, rather than a non-coding sysadmin who
> >> >> needs with work within the current NFS/gssd framework?
> >> >>
> >> >
> >> > Correct, that's what I mean. It'll mean modifying kernel and rpc.gssd
> >> > code.
> >>
> >> Thanks for confirming. Skipping back a little:
> >>
> >> >> > No, gssd (the client side daemon) will search /tmp for anything that
> >> >> > looks like a credcache for the right user, verify that it is a
> >> >> > credcache and then pick the one with the latest TGT expiration.
> >>
> >> Kevin Coffman on the NFS4 list actually implied this used simple mtime
> >> rather than actually scanning /tmp/krb5cc_uid* for ccache files with the
> >> latest TGT expiration, which is how I originally read your statement.
> >> This seemingly would make a difference in an environment with a batch job
> >> with a long lifetime ticket and subsequent interactive login generating a
> >> separate ccache file with a shorter lifetime but newer mtime.
> >>
> >> I'm not a coder but I scanned krb5_util.c in the gssd code, and it *seems*
> >> to me it only looks at mtime, although what you suggest would be more
> >> optimal. Could you confirm whether it's scanning ccache files for longest
> >> TGT, or just using mtime?
> >>
> >
> > You and Kevin are correct. rpc.gssd only looks at the mtime. When I did
> > the work to allow the CIFS SPNGEO upcall to find alternate credcaches,
> > I implemented the behavior I described (prefer the latest TGT
> > expiration) -- sorry for the confusion...
> >
> > It probably wouldn't be too hard to change rpc.gssd to prefer
> > credcaches with the latest TGT expiration if it was considered a
> > desirable change.
> >
> > Kevin, any thoughts?
>
> I agree it shouldn't be too hard to change if that behavior is desirable/useful.
Shouldn't rpc.gssd in any case be looking for all _valid_ credcaches,
rather than just any old credcache-like file?
If you stick to that principle, then if there is one file that contains
a still-unexpired TGT, and one with a TGT that has expired, then the
first file should always be preferred, irrespective of the value of the
mtimes...
Cheers
Trond
On Tue, 13 Oct 2009 12:56:20 -0400
Trond Myklebust <[email protected]> wrote:
> On Tue, 2009-10-13 at 11:51 -0400, Kevin Coffman wrote:
> > On Tue, Oct 13, 2009 at 11:44 AM, Jeff Layton <[email protected]> wrote:
> > > On Tue, 13 Oct 2009 08:28:52 -0700
> > > [email protected] wrote:
> > >
> > >> Jeff Layton <[email protected]> said:
> > >> >> Just to be clear - you mean doable to a coder who might like to improve
> > >> >> on
> > >> >> gssd/kernel credential separation, rather than a non-coding sysadmin who
> > >> >> needs with work within the current NFS/gssd framework?
> > >> >>
> > >> >
> > >> > Correct, that's what I mean. It'll mean modifying kernel and rpc.gssd
> > >> > code.
> > >>
> > >> Thanks for confirming. Skipping back a little:
> > >>
> > >> >> > No, gssd (the client side daemon) will search /tmp for anything that
> > >> >> > looks like a credcache for the right user, verify that it is a
> > >> >> > credcache and then pick the one with the latest TGT expiration.
> > >>
> > >> Kevin Coffman on the NFS4 list actually implied this used simple mtime
> > >> rather than actually scanning /tmp/krb5cc_uid* for ccache files with the
> > >> latest TGT expiration, which is how I originally read your statement.
> > >> This seemingly would make a difference in an environment with a batch job
> > >> with a long lifetime ticket and subsequent interactive login generating a
> > >> separate ccache file with a shorter lifetime but newer mtime.
> > >>
> > >> I'm not a coder but I scanned krb5_util.c in the gssd code, and it *seems*
> > >> to me it only looks at mtime, although what you suggest would be more
> > >> optimal. Could you confirm whether it's scanning ccache files for longest
> > >> TGT, or just using mtime?
> > >>
> > >
> > > You and Kevin are correct. rpc.gssd only looks at the mtime. When I did
> > > the work to allow the CIFS SPNGEO upcall to find alternate credcaches,
> > > I implemented the behavior I described (prefer the latest TGT
> > > expiration) -- sorry for the confusion...
> > >
> > > It probably wouldn't be too hard to change rpc.gssd to prefer
> > > credcaches with the latest TGT expiration if it was considered a
> > > desirable change.
> > >
> > > Kevin, any thoughts?
> >
> > I agree it shouldn't be too hard to change if that behavior is desirable/useful.
>
> Shouldn't rpc.gssd in any case be looking for all _valid_ credcaches,
> rather than just any old credcache-like file?
>
> If you stick to that principle, then if there is one file that contains
> a still-unexpired TGT, and one with a TGT that has expired, then the
> first file should always be preferred, irrespective of the value of the
> mtimes...
>
Correct...and gssd actually does check the validity of the cache. If
TGT has expired or it's not valid for some other reason, then it skips
it and moves on.
The problem comes when you have more than one valid credcache. In that
case it picks the one with the latest mtime. It seems that it should
instead pick the one with the latest TGT expiration time.
--
Jeff Layton <[email protected]>