Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Peter Staubach <staubach@redhat.com>]

J. Bruce Fields wrote:
> On Tue, Sep 01, 2009 at 02:52:44PM -0400, Peter Staubach wrote:
>> J. Bruce Fields wrote:
>>> On Tue, Sep 01, 2009 at 02:33:50PM -0400, Peter Staubach wrote:
>>>> Some servers will accept any flavor of incoming RPC security
>>>> and just use AUTH_NULL in this situation.  It really shouldn't
>>>> matter what the client sends, as long as the server is just
>>>> going to map all requests to nobody/nobody anyway...
>>> OK, but let's not pile on more workarounds than we have to.  I don't see
>>> any reason that we really need to do anything special for servers that
>>> are broken in *that* particular way....
>>>
>> I don't think that that is considered to be broken, by the way.
> 
> OK, maybe not.
> 
>> I am not sure whether it still works this way, but I know that
>> Solaris used to work this way, at the very least.
>>
>> Since I clearly haven't looked, but why would the Linux NFS
>> server care which flavor that it got sent, if the export is
>> configured to map all requests to nobody/nobody?
> 
> I can think of any number of reasons, but on the client side I don't see
> any great advantage to taking "auth_null" to mean "use anything you
> want": it's another special case, it's undocumented and will only work
> on some servers, and if it's really what the administrator wants, it
> should be easy to fix the server to advertise everything while still
> doing the id-squashing.
> 

I don't understand this last.  Why would the server bother to
advertise the various flavors if they are all going to treated
as if they were AUTH_NONE?  It would seem to violate expectations
that clients may have, that they issued authentic and verifiable
requests, only to be treated as if they were not?

Just out of curiosity, any number of reasons?  :-)

This all seems like a lot of conversation and work just to try
to figure out how to accommodate a configuration which has
already indicated that it will ignore any incoming authentication
information.  I would suggest that we take the easy and obvious
way of sending AUTH_UNIX to such systems and if we find one that
really insists upon receiving AUTH_NONE from the client, then
we fix the client.  Many clients can't even generate AUTH_NONE,
by the way...

		ps

		ps