[38578] in Kerberos
Re: krb5 library missing functions for collections
daemon@ATHENA.MIT.EDU (Simo Sorce)
Tue Jul 23 09:36:33 2019
Message-ID: <15b7b8659500dfb6c54f31419392556e4a956b65.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Charles Hedrick <hedrick@rutgers.edu>, Greg Hudson <ghudson@mit.edu>
Date: Tue, 23 Jul 2019 09:35:29 -0400
In-Reply-To: <50662F97-B34B-4C2F-8D39-FBC8C11F3375@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 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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
