[38582] in Kerberos
Re: krb5 library missing functions for collections
daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Jul 23 10:58:27 2019
Message-ID: <4a606ef89323071b154ee9688db7cb7c3b719adc.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Charles Hedrick <hedrick@rutgers.edu>
Date: Tue, 23 Jul 2019 10:58:12 -0400
In-Reply-To: <30F14463-F3D0-4EAB-BA26-584B0E121E7C@rutgers.edu>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, 2019-07-23 at 14:09 +0000, Charles Hedrick wrote:
> Maybe there’s a path through the code that I didn’t find. But it ends
> up failing if the credential isn’t username@DOMAIN. There’s an
> explicit test. I don’t see why it couldn't specify that in the first
> place.
>
> I think if you want a local user joe to access NFS as jdoe@REALM,
> you’d want to set up that mapping somewhere. I haven’t checked this
> in the code, but I’d expect it in a krb5.conf mapping, .k5identity,
> and/or idmap. I doubt you want NFS to use whatever random ticket may
> be in the default cache for the uid making the access. As far as I
> can tell it doesn’t actually do that now.
Actually this is how NFS is supposed to work, it will pick the first
valid credential, but it is possible a later change broke it.
.k5identity is also an option but as a way to select a non-default
principal, if you have only one krbtgt regardless of what it is I
expect an NFS mount to try to use that credential.
Simo.
> > On Jul 23, 2019, at 9:35 AM, Simo Sorce <simo@redhat.com> wrote:
> >
> > On Mon, 2019-07-22 at 20:10 +0000, Charles Hedrick wrote:
> > > The problem is that the code in rpc.gssd works as followers:
> > >
> > > * get the default credential from the collection
> > > * fail unless it’s username@DOMAIN
> > >
> > > If you replace the initial step by code telling it explicitly to get
> > > username@DOMAIN then it works just fine, assuming that the user
> > > actually has such a credential. Which they will. GSSAPI is perfectly
> > > capable of looking for a specific credential if you tell it to. It’s
> > > just that the code doesn’t do it that way. To avoid building my own
> > > copy of rpc.gssd, I use a loadable library to interpose code around
> > > GSSAPI that supplies the right argument.
> >
> > rpc.gssd does this because it cannot know what the right credential
> > name is in all situations.
> >
> > In very controlled environments it is indeed username + @REALM and the
> > realm is known, but in other cases it is not.
> > For example a personal laptop where the username is 'joe' and no
> > default realm is set and someone doing kinit jdoe@WORK.REALM then
> > walking into an NFS mount.
> >
> > I guess the nfs-utils folks may accept a patch to rpc.gssd where an
> > option can be given to assume a specific form for the user's principal
> > name to look for, but that can't be the default as it would break
> > current uses.
> >
> > HTH,
> > Simo.
> >
> > --
> > Simo Sorce
> > RHEL Crypto Team
> > Red Hat, Inc
> >
> >
> >
> >
>
>
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
