Re: [PATCH 1/1 v2] systemd: Only start the gssd daemons when they are enabled

[Chuck Lever <chuck.lever@oracle.com>]

> On Jun 28, 2016, at 2:12 PM, Steve Dickson <SteveD@redhat.com> wrote:
> 
> 
> 
>> On 06/28/2016 01:23 PM, Weston Andros Adamson wrote:
>> 
>>>> On Jun 28, 2016, at 12:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> 
>>>> 
>>>> On Jun 28, 2016, at 10:27 AM, Steve Dickson <SteveD@redhat.com> wrote:
>>>> 
>>>> Again, sorry for the delay... That darn flux capacitor broke... again!!! :-)
>>>> 
>>>>> On 06/23/2016 09:30 PM, Chuck Lever wrote:
>>>>> 
>>>>>> On Jun 23, 2016, at 11:57 AM, Steve Dickson <SteveD@redhat.com> wrote:
>>>> 
>>>> [snip]
>>>> 
>>>>>> the key tab does have a nfs/hosname@REALM entry. So the 
>>>>>> call to the KDC is probably failing... which 
>>>>>> could be construed as a misconfiguration, but
>>>>>> that misconfiguration should not even come into 
>>>>>> play with sec=sys mounts... IMHO...
>>>>> 
>>>>> I disagree, of course. sec=sys means the client is not going
>>>>> to use Kerberos to authenticate individual user requests,
>>>>> and users don't need a Kerberos ticket to access their files.
>>>>> That's still the case.
>>>>> 
>>>>> I'm not aware of any promise that sec=sys means there is
>>>>> no Kerberos within 50 miles of that mount.
>>>> I think that's is the assumption... No Kerberos will be
>>>> needed for sec=sys mounts. Its not when Kerberos is 
>>>> not configured.
>>> 
>>> NFSv3 sec=sys happens to mean that no Kerberos is needed.
>>> This hasn't changed either.
>>> 
>>> NFSv4 sec=sys is different. Just like NFSv4 ACLs, and
>>> NFSv4 ID mapping, and NFSv4 locking, and so on.
>>> 
>>> Note though that Kerberos isn't needed for NFSv4 sec=sys
>>> even when there is a keytab. The client negotiates and
>>> operates without it.
>>> 
>>> 
>>>>> If there are valid keytabs on both systems, they need to
>>>>> be set up correctly. If there's a misconfiguration, then
>>>>> gssd needs to report it precisely instead of time out.
>>>>> And it's just as easy to add a service principal to a keytab
>>>>> as it is to disable a systemd service in that case.
>>>> I think its more straightforward to disable a service
>>>> that is not needed than to have to add a principal to a 
>>>> keytab for a service that's not being used or needed.
>>> 
>>> IMO automating NFS setup so that it chooses the most
>>> secure possible settings without intervention is the
>>> best possible solution.
>>> 
>>> 
>>>>>>> Is gssd waiting for syslog or something?
>>>>>> No... its just failing to get the machine creds for root
>>>>> 
>>>>> Clearly more is going on than that, and so far we have only
>>>>> some speculation. Can you provide an strace of rpc.gssd or
>>>>> a network capture so we can confirm what's going on?
>>>> Yes... Yes... and Yes.. I added you to the bz...
>>> 
>>> Thanks! I'll have a look at it.
>>> 
>>> 
>>>>>> [snip]
>>>>>> 
>>>>>>>> Which does work and will still work... but I'm thinking it is
>>>>>>>> much similar to disable the service via systemd command
>>>>>>>> systemctl disable rpc-gssd
>>>>>>>> 
>>>>>>>> than creating and editing those .conf files.
>>>>>>> 
>>>>>>> This should all be automatic, IMO.
>>>>>>> 
>>>>>>> On Solaris, drop in a keytab and a krb5.conf, and add sec=krb5
>>>>>>> to your mounts. No reboot, nothing to restart. Linux should be
>>>>>>> that simple.
>>>>>> The only extra step with Linux is to 'sysctmctl start rpc-gssd'
>>>>>> I don't there is much would can do about that....
>>>>> 
>>>>> Sure there is. Leave gssd running, and make sure it can respond
>>>>> quickly in every reasonable case. :-p
>>>>> 
>>>>> 
>>>>>> But of
>>>>>> course... Patches are always welcomed!! 8-)
>>>>>> 
>>>>>> TBL... When kerberos is configured correctly for NFS everything
>>>>>> works just fine. When kerberos is configured, but not for NFS,
>>>>>> causes delays on all NFS mounts.
>>>>> 
>>>>> This convinces me even more that there is a gssd issue here.
>>>>> 
>>>>> 
>>>>>> Today, there is a method to stop rpc-gssd from blindly starting
>>>>>> when kerberos is configured to eliminate that delay.
>>>>> 
>>>>> I can fix my broken TV by not turning it on, and I don't
>>>>> notice the problem. But the problem is still there any
>>>>> time I want to watch TV.
>>>>> 
>>>>> The problem is not fixed by disabling gssd, it's just
>>>>> hidden in some cases.
>>>> I agree this %100... All I'm saying there should be a 
>>>> way to disable it when the daemon is not needed or used.
>>> 
>>> NFSv4 sec=sys *does* use Kerberos, when it is available.
>>> It has for years.
>>> 
>>> Documentation should be updated to state that if Kerberos
>>> is configured on clients, they will attempt to use it to
>>> manage some operations that are common to all NFSv4 mount
>>> points on that client, even when a mount point uses sec=sys.
>>> 
>>> Kerberos will be used for user authentication only if the
>>> client administrator has not specified a sec= setting, but
>>> the server export allows the use of Kerberos; or if the
>>> client administrator has specified a sec=krb5, sec=krb5i,
>>> or sec=krb5p setting.
>>> 
>>> The reason for using Kerberos for common operations is
>>> that a client may have just one lease management principal.
>>> If the client uses sec=sys and sec=krb5 mounts, and the
>>> sec=sys mount is done first, then lease management would use
>>> sys as well. The client cannot change this principal after
>>> it has established a lease and files are open.
>>> 
>>> A subsequent sec=krb5 mount will also use sec=sys for
>>> lease management. This will be surprising and insecure
>>> behavior. Therefore, all mounts from this client attempt
>>> to set up a krb5 lease management transport.
>> 
>> Chuck,
>> 
>> Thanks for explaining this so well! This definitely should make
>> it’s way into documentation - we should have added something
>> like this a long time ago.
> I agree... where should it go? the mount.nfs man page??

nfs(5) is where this kind of thing typically goes.