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. > On Jul 23, 2019, at 9:35 AM, Simo Sorce <s...@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 > > > > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
