Re: [PATCH] Adding the nfs4_use_min_auth module parameter

[Steve Dickson <SteveD@redhat.com>]

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.
Thank you for point this out... That does change things... IMHO...

steved.

> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>