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 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?
--
Jeff Layton <[email protected]>
> 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?
This would be a big plus from me - I still wouldn't be able to create
per-job ccaches of course, but if a user who knew they needed to run a job
could create a long lifetime renewable ticket in /tmp/krb5cc_<uid>_batch,
say, and NFS would use this in preference to a later login ticket, this
would really help.
On Tue, 13 Oct 2009 13:31:38 -0400
Jeff Layton <[email protected]> wrote:
> On Tue, 13 Oct 2009 08:59:29 -0700
> [email protected] wrote:
>
> >
> > > 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?
> >
> > This would be a big plus from me - I still wouldn't be able to create
> > per-job ccaches of course, but if a user who knew they needed to run a job
> > could create a long lifetime renewable ticket in /tmp/krb5cc_<uid>_batch,
> > say, and NFS would use this in preference to a later login ticket, this
> > would really help.
> >
> >
>
> Ok, here's a proposed patch...only compile-tested so far. I don't have
> time at the moment to test it more extensively so if you could test it
> out and report back, that would be helpful.
>
Looks like this patch will probably break the "preferred realm" code.
It'll have to be respun to fix that, but it should work as expected in
a single-realm environment.
--
Jeff Layton <[email protected]>
On Tue, 13 Oct 2009 08:59:29 -0700
[email protected] wrote:
>
> > 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?
>
> This would be a big plus from me - I still wouldn't be able to create
> per-job ccaches of course, but if a user who knew they needed to run a job
> could create a long lifetime renewable ticket in /tmp/krb5cc_<uid>_batch,
> say, and NFS would use this in preference to a later login ticket, this
> would really help.
>
>
Ok, here's a proposed patch...only compile-tested so far. I don't have
time at the moment to test it more extensively so if you could test it
out and report back, that would be helpful.
Thanks,
--
Jeff Layton <[email protected]>
On Wed, 14 Oct 2009 10:00:59 -0700
[email protected] wrote:
> > On Tue, 13 Oct 2009 08:59:29 -0700
> > [email protected] wrote:
> >
> >> > 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?
> >>
> >> This would be a big plus from me - I still wouldn't be able to create
> >> per-job ccaches of course, but if a user who knew they needed to run a
> >> job
> >> could create a long lifetime renewable ticket in
> >> /tmp/krb5cc_<uid>_batch,
> >> say, and NFS would use this in preference to a later login ticket, this
> >> would really help.
> >
> > Ok, here's a proposed patch...only compile-tested so far. I don't have
> > time at the moment to test it more extensively so if you could test it
> > out and report back, that would be helpful.
>
> Thanks Jeff - this looks extremely useful, caveat my other comment (and
> perhaps lack of understanding) on the list today about what's happened in
> recent nfs-utils which I'd like to clarify.
>
> I may have trouble testing this in the short term as I'm largely bound to
> production environments - but will get to back to you if I can.
>
Actually...I'm not convinced that it is that useful. As Trond pointed
out, when the credentials expire, the kernel should upcall for new
creds. As long as there is a valid TGT in a credcache for that user
somewhere then it should just pick up that one and keep humming along.
If that's not working for some reason then that's likely a bug.
--
Jeff Layton <[email protected]>
> On Tue, 13 Oct 2009 08:59:29 -0700
> [email protected] wrote:
>
>> > 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?
>>
>> This would be a big plus from me - I still wouldn't be able to create
>> per-job ccaches of course, but if a user who knew they needed to run a
>> job
>> could create a long lifetime renewable ticket in
>> /tmp/krb5cc_<uid>_batch,
>> say, and NFS would use this in preference to a later login ticket, this
>> would really help.
>
> Ok, here's a proposed patch...only compile-tested so far. I don't have
> time at the moment to test it more extensively so if you could test it
> out and report back, that would be helpful.
Thanks Jeff - this looks extremely useful, caveat my other comment (and
perhaps lack of understanding) on the list today about what's happened in
recent nfs-utils which I'd like to clarify.
I may have trouble testing this in the short term as I'm largely bound to
production environments - but will get to back to you if I can.