Re: Strange rpc.svcgssd behavior

[Kevin Coffman <kwc@citi.umich.edu>]

On Wed, Nov 17, 2010 at 11:05 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On Nov 17, 2010, at 10:54 AM, Kevin Coffman wrote:
>
>> On Wed, Nov 17, 2010 at 10:30 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>> Hey-
>>>
>>> On Nov 17, 2010, at 10:18 AM, Steve Dickson wrote:
>>>
>>>> Sorry for the delayed response... I had my
>>>> head down for last couple of days...
>>>>
>>>> On 11/16/2010 04:42 PM, Chuck Lever wrote:
>>>>>
>>>>> On Nov 16, 2010, at 3:54 PM, Jim Rees wrote:
>>>>>
>>>>>> Chuck Lever wrote:
>>>>>>
>>>>>> Before we go too far down the NM path of no return, I was under the
>>>>>> impression that some applications require the host's name on the localhost
>>>>>> entries in /etc/hosts.  That's why NM puts it there.
>>>>>>
>>>>>> There's nothing invalid about having a hostname on the localhost entries
>>>>>> in /etc/hosts, is there?
>>>>>>
>>>>>> So I wonder if removing NM is really the solution here.
>>>>>>
>>>>>> No, it's not.  I just like to complain about NM.
>>>>>>
>>>>>> The original problem was that rpc.svcgssd couldn't figure out the correct
>>>>>> kerberos realm.  The fix in this particular case, I think, is to set the
>>>>>> realm explicitly in /etc/idmapd.conf.
>>>>>
>>>>> It's having trouble determining the NFS server's hostname.  It needs to find the right nfs/your.host key in /etc/krb5.keytab.
>>>>>
>>>>> I don't know if realm self-discovery is an issue too.
>>>> I think the problem is a reverse lookup is done on hostname that
>>>> is found in the /etc/krb5.keytab. Instead of the FQDN being
>>>> returned, localhost is returned because the FQDN was added to
>>>> the localhost line in /etc/hosts.
>>>>
>>>> Actually I didn't realize it was NM doing that... I thought
>>>> it was the installer...
>>>
>>> No matter who does it, I think there are applications
>>> (gdm?  rusty recollection) that require this network configuration
>>> in /etc/hosts, so our best bet IMO is to fix rpc.svcgssd, or more
>>> likely the gss library it depends on, to get it right in this situation.
>>> If we all agree this is a bug (and sounds like we do) then I can
>>> create a bug report on bugzilla.linux-nfs.org, as a starting point.
>>
>> Hi Chuck and Steve,
>> This issue affects gss authentication in sshd as well.  I believe this
>> is all the way down in the Kerberos code, which has been this way for
>> years.  I'm not sure what needs to be changed to "get it right".
>
> I was afraid of that.  Do you know if this has this ever been brought
> up with the upstream Kerberos maintainers?

Not that I am aware of.  Like Valentin, I believe it to be a
NetworkManager bug.  (The Kerberos code works fine on all other Unix
platforms.)

K.C.