On Nov 8, 2013, at 7:21, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 07/11/13 17:29, Myklebust, Trond wrote: >>> Again, what servers, today, support this type of secure state establishment? >>>> Having this type of security in the client I think is good... but if >>>> the client is not talking with any servers that support this type >>>> of security, why not have a way to turn it off? >> I don't understand. Servers are _required_ to support RPCSEC_GSS with >> krb5 by both RFC3530 and RFC5661. AUTH_SYS is, in fact, the optional >> flavour. > Agreed... 100% of the NFSv4 server have to support RPCSEC_GSS. its mandated > by the spec(s). > >> >> The problem here is that sometimes kerberos isn't configured by the >> admin, who then expects that it shouldn't be necessary to run rpc.gssd >> or rpc.svcgssd. It is necessary because we first try the >> mandatory-to-implement and secure RPCSEC_GSS/krb5i flavour before >> falling back to the less secure AUTH_SYS... > Sometimes? Its generally not.. from my experience... > > Basically how I interpret this last paragraph, is we will be requiring > admins set up secure mounts for them to avoid the 15sec delay mount > times... aka... running a daemon that will say "no, no there is no > security here" while spewing of log messages when Kerberos is not setup... No. All we are requiring is that they run rpc.gssd. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
