interaction between caches, KEYRING, and NFS

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

interaction between caches, KEYRING, and NFS

Charles Hedrick
The KEYRING mechanism is nice, in many ways. But it has some unexpected effects.

There’s a “primary” key for the usual keyring. But this is a global object. That is, which cache is primary is the same for all sessions, and for NFS.

Imagine I’m a privileged user. I start out logged in as [hidden email]<mailto:[hidden email]>. I now decide to do some administrative work. I kinit as [hidden email]<mailto:[hidden email]>. What happens depends upon exactly how KRB5CCNAME is set.

Depending upon how I logged in, KRB5CCNAME may be set either to KEYRING:persistent:NNN or KEYRING:persistent:NNN:XXX.

If it’s set to KEYRING:persistent:NNN:XXX, kinit will fail with an error "kinit: Can't create new subsidiary cache because default cache is already a subsidiary while generating new ccache.” Also, “klist -l” will fail. Actually, it will appear to work, but only show me the one cache even if there are others.

If KRB5CCNAME is set to KEYRING:persistent:NNN, kinit will work. It will create a new cache for the new credentials, and make it primary. The problem with making it primary is that if NFS happens to check my credentials at that point it will fail. rpc.gssd uses a GSSAPI interface that only checks the primary credentials. Of course admin won’t mean anything to NFS, since my file access will all need to be done as hedrick.

About the best I could come up with is to wrap kinit with a script that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit, so it always works. It then does kswitch to switch back to my primary cache, so that NFS doesn’t break. Finally, it checks whether with my original setting of KRB5CCNAME I’ll see the cache I just set up. There’s a good chance I won’t. In that case it prints a command to set KRB5CCNAME appropriately, which I can cut and paste.

I also have a skshow, which helps me switch between caches if I don’t need to reauthentication. “skshow principal” looks for a cache for that principal and prints a command line to set KRB5CCNAME appropriately.

If anyone has better ideas I’d love to hear them.

(I note that using FILE rather than KEYRING doesn’t produce results that are as surprising, but I’d still want wrapper scripts to help maintain multiple caches.)



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: interaction between caches, KEYRING, and NFS

Simo Sorce-3
On Tue, 2017-03-14 at 18:59 +0000, Charles Hedrick wrote:

> The KEYRING mechanism is nice, in many ways. But it has some
> unexpected effects.
>
> There’s a “primary” key for the usual keyring. But this is a global
> object. That is, which cache is primary is the same for all sessions,
> and for NFS.
>
> Imagine I’m a privileged user. I start out logged in as [hidden email]
> TGERS.EDU<mailto:[hidden email]>. I now decide to do some
> administrative work. I kinit as [hidden email]<mailto:hedrick.a
> [hidden email]>. What happens depends upon exactly how
> KRB5CCNAME is set.
>
> Depending upon how I logged in, KRB5CCNAME may be set either to
> KEYRING:persistent:NNN or KEYRING:persistent:NNN:XXX.
>
> If it’s set to KEYRING:persistent:NNN:XXX, kinit will fail with an
> error "kinit: Can't create new subsidiary cache because default cache
> is already a subsidiary while generating new ccache.” Also, “klist
> -l” will fail. Actually, it will appear to work, but only show me the
> one cache even if there are others.
>
> If KRB5CCNAME is set to KEYRING:persistent:NNN, kinit will work. It
> will create a new cache for the new credentials, and make it primary.
> The problem with making it primary is that if NFS happens to check my
> credentials at that point it will fail. rpc.gssd uses a GSSAPI
> interface that only checks the primary credentials. Of course admin
> won’t mean anything to NFS, since my file access will all need to be
> done as hedrick.
>
> About the best I could come up with is to wrap kinit with a script
> that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit, so
> it always works. It then does kswitch to switch back to my primary
> cache, so that NFS doesn’t break. Finally, it checks whether with my
> original setting of KRB5CCNAME I’ll see the cache I just set up.
> There’s a good chance I won’t. In that case it prints a command to
> set KRB5CCNAME appropriately, which I can cut and paste.
>
> I also have a skshow, which helps me switch between caches if I don’t
> need to reauthentication. “skshow principal” looks for a cache for
> that principal and prints a command line to set KRB5CCNAME
> appropriately.
>
> If anyone has better ideas I’d love to hear them.
>
> (I note that using FILE rather than KEYRING doesn’t produce results
> that are as surprising, but I’d still want wrapper scripts to help
> maintain multiple caches.)

Set KRB5CNAME to a FILE ccache for administrative work so that it is
completely disjoint from your user ccaches and NFS will not have to
deal with it. Or make sure to walk into the NFS mount points with your
user before doing admin work.

Simo.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: interaction between caches, KEYRING, and NFS

tibbs (Bugzilla)
In reply to this post by Charles Hedrick
>>>>> "CH" == Charles Hedrick <[hidden email]> writes:

CH> The KEYRING mechanism is nice, in many ways. But it has some
CH> unexpected effects.

It's always good to mention the actual OS you are using.  I know most
modern Linux distros provide the KEYRING CCACHE type which uses the
kernel's keyring facility.

CH> If it’s set to KEYRING:persistent:NNN:XXX, kinit will fail with an
CH> error "kinit: Can't create new subsidiary cache because default
CH> cache is already a subsidiary while generating new ccache.”

I did file a ticket when I ran into this in Fedora ages ago.  The Fedora
ticket has since been resolved, but it was cloned into an RHEL ticket
which lives on at https://bugzilla.redhat.com/show_bug.cgi?id=1278017.

CH> Also,
CH> “klist -l” will fail. Actually, it will appear to work, but only
CH> show me the one cache even if there are others.

Works for me in Fedora 25:

ἐπιθυμία:~❯ klist -l
Principal name                 Cache name
--------------                 ----------
[hidden email]              KEYRING:persistent:7225:krb_ccache_CLoU6wS
[hidden email]        KEYRING:persistent:7225:krb_ccache_1FSCnNf

CH> The problem with making it primary is that if NFS happens
CH> to check my credentials at that point it will fail. rpc.gssd uses a
CH> GSSAPI interface that only checks the primary credentials.

I think this is heavily OS and version dependent.  Might also depend on
gssproxy.

CH> About the best I could come up with is to wrap kinit with a script
CH> that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit,
CH> so it always works.

I would suggest just using FILE: so there's no chance of the admin
CCACHE messing with your user credentials.

For the future I have some hope that the plans for SSSD to provide a
CCACHE type will help with a number of issues.  I have had very good
experiences with SSSD and its developers and have some confidence that
they'll come up with something useful.  This was planned to be a Fedora
26 feature but didn't quite make it in time, but I imagine the code will
come along in time.
https://fedoraproject.org/wiki/Changes/KerberosKCMCache has some info.

 - J<

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: interaction between caches, KEYRING, and NFS

Charles Hedrick
Actually, if I have KRB5CCNAME set to a file in /tmp, and kinit as someone else, e.g. admin, that will reinitialize the file in /tmp, losing my original credentials.

With KEYRING (I’m using Centos 7), because it’s a collection, there’s some hope of maintaining multiple caches properly. If KRB5CCNAME is set to the collection, kinit is smart enough to create a new credentials cache. With FILE:, I’d need to reset KRB5CCNAME or using an explicit -c option to kinit. The problem is that kinit makes the new cache primary. Without NFS that makes sense. With NFS, it can cause trouble.

I see two reasonable solutions:

 * Have rpc.gssd look at the whole KEYRING collection and not just the primary. I don’t think that’s a hard patch, though having GSSAPI on top of Kerberos makes everything more difficult to figure out.
* Have the primary member of the collection be session-specific. But you’d probably need to combine that with the first.

I’m thinking of generating a bug report for rpc.gssd.

On Mar 16, 2017, at 12:26 PM, Jason L Tibbitts III <[hidden email]<mailto:[hidden email]>> wrote:

CH> About the best I could come up with is to wrap kinit with a script
CH> that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit,
CH> so it always works.

I would suggest just using FILE: so there's no chance of the admin
CCACHE messing with your user credentials.

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Loading...