Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:48606 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752119AbcF1SNA (ORCPT ); Tue, 28 Jun 2016 14:13:00 -0400 Subject: Re: [PATCH 1/1 v2] systemd: Only start the gssd daemons when they are enabled To: Weston Andros Adamson , Chuck Lever References: <1466520807-4340-1-git-send-email-steved@redhat.com> <09ECB137-8EC4-4713-B5F4-44D0405B2700@oracle.com> <1D39CEF6-AC29-4166-95DF-ADBD2C0286B3@oracle.com> <73CFA6F9-C983-47D7-972C-9DF782731F3C@oracle.com> <2085406d-1e41-46b2-6791-2a3208f5497b@RedHat.com> <5940600C-CF7E-46EA-804C-A67A6F9D52E3@monkey.org> Cc: linux-nfs list From: Steve Dickson Message-ID: Date: Tue, 28 Jun 2016 14:12:54 -0400 MIME-Version: 1.0 In-Reply-To: <5940600C-CF7E-46EA-804C-A67A6F9D52E3@monkey.org> Content-Type: text/plain; charset=windows-1252 Sender: linux-nfs-owner@vger.kernel.org List-ID: On 06/28/2016 01:23 PM, Weston Andros Adamson wrote: > >> On Jun 28, 2016, at 12:27 PM, Chuck Lever wrote: >> >>> >>> On Jun 28, 2016, at 10:27 AM, Steve Dickson 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 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?? steved.