> On Jun 28, 2016, at 2:12 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > >> On 06/28/2016 01:23 PM, Weston Andros Adamson wrote: >> >>>> On Jun 28, 2016, at 12:27 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>> >>>> On Jun 28, 2016, at 10:27 AM, Steve Dickson <SteveD@xxxxxxxxxx> 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@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
