[38581] in Kerberos
Re: krb5 library missing functions for collections
daemon@ATHENA.MIT.EDU (Charles Hedrick)
Tue Jul 23 10:51:29 2019
From: Charles Hedrick <hedrick@rutgers.edu>
To: Simo Sorce <simo@redhat.com>
Date: Tue, 23 Jul 2019 14:51:14 +0000
Message-ID: <6FD822B4-4F0A-4CD3-8164-4EFC469DD27E@rutgers.edu>
In-Reply-To: <30F14463-F3D0-4EAB-BA26-584B0E121E7C@rutgers.edu>
Content-Language: en-US
Content-ID: <7A67790C2433E545BB33B40B703F9C16@namprd14.prod.outlook.com>
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
this is worse than it looks. Documentation says that GSSAPI will obey .k5identity. That’s the right solution for you situation of the laptop user with a different username.
The problem is that there’s no system-wide equivalent of .k5identity. My code causes problems, because in specifying a particular principle it bypasses .k5identity. But for the normal case we don’t want every user to have to specify a .k5identity. I suspect the right thing for me to do is rather than hack rpc.gssd, supply a cc_select plugin to make the obvious selection for service=nfs. But I claim this ought to be the default. I shouldn’t have to do C coding to make it happen.
> On Jul 23, 2019, at 10:09 AM, Charles Hedrick <hedrick@rutgers.edu> 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.
>
>> 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
>>
>>
>>
>>
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
