On Nov 8, 2013, at 10:08, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 08/11/13 09:30, Myklebust, Trond wrote: >> >> 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. > Even when they do not want any secure mounts at all? > > What is that justification? They get to skip a 15 second wait without having to blacklist the krb5 module. So, this is what I mean when I say that we _might_ need a mount option to specify the security flavour that the client uses for the lease. It solves the problem that Bruce mentioned about what to do when krb5i fails, and it allows admins to not have to run rpc.gssd or blacklist any modules. Trond -- 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
