Re: [PATCH] Adding the nfs4_use_min_auth module parameter

["J. Bruce Fields" <bfields@fieldses.org>]

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@redhat.com> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 08/11/13 08:22, Jeff Layton wrote:
> >>>>>>> On Fri, 08 Nov 2013 07:41:32 -0500
> >>>>>>> Steve Dickson <SteveD@redhat.com> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 07/11/13 18:05, Chuck Lever wrote:
> >>>>>>>>>
> >>>>>>>>> On Nov 7, 2013, at 1:35 PM, Steve Dickson <SteveD@redhat.com> 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@redhat.com> 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.

> 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.

--b.