On 08/11/13 11:39, J. Bruce Fields wrote: > On Fri, Nov 08, 2013 at 11:28:02AM -0500, Steve Dickson wrote: >> >> >> On 08/11/13 11:22, J. Bruce Fields wrote: >>> On Fri, Nov 08, 2013 at 11:19:45AM -0500, Steve Dickson wrote: >>>> >>>> >>>> On 08/11/13 11:17, J. Bruce Fields wrote: >>>>> On Fri, Nov 08, 2013 at 11:10:14AM -0500, Steve Dickson wrote: >>>>>> >>>>>> >>>>>> On 08/11/13 10:12, Jeff Layton wrote: >>>>>>> On Fri, 08 Nov 2013 10:00:02 -0500 >>>>>>> Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 08/11/13 08:22, Jeff Layton wrote: >>>>>>>>> On Fri, 08 Nov 2013 07:41:32 -0500 >>>>>>>>> Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/11/13 18:05, Chuck Lever wrote: >>>>>>>>>>> >>>>>>>>>>> On Nov 7, 2013, at 1:35 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hey mrchuck... >>>>>>>>>>>> >>>>>>>>>>>> On 07/11/13 14:25, Chuck Lever wrote: >>>>>>>>>>>>> Hi Steve- >>>>>>>>>>>>> >>>>>>>>>>>>> On Nov 7, 2013, at 11:09 AM, Steve Dickson <steved@xxxxxxxxxx> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> This new module parameter makes the v4 client >>>>>>>>>>>>>> use the minimal authentication flavor (AUTH_UNIX) >>>>>>>>>>>>>> when establishing NFSV4 state and doing the >>>>>>>>>>>>>> pseudoroot lookup >>>>>>>>>>>>> >>>>>>>>>>>>> The patch description doesn't say, but is this change to work >>>>>>>>>>>>> around the 15 second GSSD upcall timeout? >>>>>>>>>>>> Yes. A 15 second delay on every mount due to security that >>>>>>>>>>>> nobody is requesting is just not good.. IMHO.. >>>>>>>>>>> >>>>>>>>>>> One thing we haven't discussed is reducing the upcall timeout to 5 seconds or less, >>>>>>>>>>> as a form of immediate relief. 15 seconds is arbitrary, and is onerous even when >>>>>>>>>>> you expect the mount to work (ie why would it be good for any properly configured >>>>>>>>>>> environment to take 15 seconds to establish a GSS context?). >>>>>>>>>>> >>>>>>>>>>> In other words, there are still cases where users wait 15 seconds unnecessarily, >>>>>>>>>>> and not because of the use of krb5i for lease management. Aren't those of concern? >>>>>>>>>> No. I think the concern here, at least my concern, is the lack of management. >>>>>>>>>> We are forcing admins to use krb5i in lease management when its not necessary >>>>>>>>>> and there is no way to turn it off. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I don't think that's really the case. The idea was to have the client >>>>>>>>> attempt to use krb5i if it's available, and then to fall back to >>>>>>>>> AUTH_SYS if it isn't. This would be *absolutely* no big deal if the >>>>>>>>> GSSAPI upcall succeeded or failed immediately instead of requiring this >>>>>>>>> timeout when the daemon isn't running. >>>>>>>> What server makes krb5i available today in state setup and pseudoroot lookups? >>>>>>>> >>>>>>> >>>>>>> That I don't know...sorry... >>>>>> Then what is the justification to take all these extra steps >>>>>> there they going to fail %100 of the time?? >>>>> >>>>> Any server can support krb5 for state setup and pseudoroot operations if >>>>> it's configured. This isn't a problem. >>>> Would is this done on a Linux server? Is there a wiki? >>> >>> It's allowed by default, there should be nothing to configure beyond the >>> usual krb5 setup. >> Great! So you are saying when rpc.gssd is up and Kerberos is correctly >> configured on both the server and client the state setup and pseudoroot >> become secured? > > Yes. > > There's one possible exception: I think mountd currently may not allow > krb5 on the pseudoroot if it's not allowed on some export? > > We could fix that if it's a problem here. (I don't think it is, because > a client mounting with auth_sys will fall back on auth_sys in this case, > and a client mounting with sec=krb5 is going to fail eventually anyway.) > > The server will allow state setup regardless. This is good to know... Thanks! > >> And this is the case with other non-Linux servers? > > Yes, the client's always used krb5 for all that setup at least in the > case where the first mount uses sec=krb5. And we test that at > connectathon/bakeathon, and it's probably one of the first things anyone > writing new gss support for a server would try. It would be good to get all this documented... If its not already... steved. > > --b. > -- 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
