On Mon, Aug 24, 2009 at 01:06:58PM -0400, Trond Myklebust wrote:
> On Mon, 2009-08-24 at 12:10 -0400, J. Bruce Fields wrote:
> > On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
> > > On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
> > > > On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
> > > > > On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
> > > > > > 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
> > > > > > list.
> > > > >
> > > > > Does the server support auth_null security? I didn't think it did.
> > > >
> > > > Just off the top of my head, without looking at the code: I believe it
> > > > treats auth_null rpc calls exactly as if they were auth_sys calls with
> > > > uid and gid set to the "anonymous" uid and gid.
> > >
> > > OK, so that would break too.
> >
> > I've lost track of the antecedent to "that".
>
> Negotiating AUTH_NULL security for those mountd programs that fake up a
> list of flavours that excludes AUTH_NULL.
OK, got it.
(And note (a reminder to anyone that forgot) the omission of AUTH_NULL
is a workaround for a bug in older mount.nfs which caused the client to
prefer flavors at the end of the list. (Fixed in 3c1bb23c03, which went
into 1.1.3. When was that bug introduced?) That means some clients
read the list forwards, and some backwards, so if you want clients to
avoid picking AUTH_NULL by default, there's no safe place to put it.
Since AUTH_NULL seems rarely needed, it seemed best just to leave it
off.)
Anyway, we could add a second special case on the client side that
allowed an explicit sec=null to bypass checking against the server list.
I don't know who actually needs mounts with sec=null.
And/or we could plan to put AUTH_NULL back on the server's list some
day, depending on how widely disseminated we think the backwards mount
behavior was....
--b.
On Aug 24, 2009, at 1:41 PM, J. Bruce Fields wrote:
> On Mon, Aug 24, 2009 at 01:06:58PM -0400, Trond Myklebust wrote:
>> On Mon, 2009-08-24 at 12:10 -0400, J. Bruce Fields wrote:
>>> On Fri, Aug 21, 2009 at 05:51:02PM -0400, Trond Myklebust wrote:
>>>> On Fri, 2009-08-21 at 17:47 -0400, J. Bruce Fields wrote:
>>>>> On Fri, Aug 21, 2009 at 05:40:36PM -0400, Trond Myklebust wrote:
>>>>>> On Fri, 2009-08-21 at 17:30 -0400, J. Bruce Fields wrote:
>>>>>>> 3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
>>>>>>> list.
>>>>>>
>>>>>> Does the server support auth_null security? I didn't think it
>>>>>> did.
>>>>>
>>>>> Just off the top of my head, without looking at the code: I
>>>>> believe it
>>>>> treats auth_null rpc calls exactly as if they were auth_sys
>>>>> calls with
>>>>> uid and gid set to the "anonymous" uid and gid.
>>>>
>>>> OK, so that would break too.
>>>
>>> I've lost track of the antecedent to "that".
>>
>> Negotiating AUTH_NULL security for those mountd programs that fake
>> up a
>> list of flavours that excludes AUTH_NULL.
>
> OK, got it.
>
> (And note (a reminder to anyone that forgot) the omission of AUTH_NULL
> is a workaround for a bug in older mount.nfs which caused the client
> to
> prefer flavors at the end of the list. (Fixed in 3c1bb23c03, which
> went
> into 1.1.3. When was that bug introduced?) That means some clients
> read the list forwards, and some backwards, so if you want clients to
> avoid picking AUTH_NULL by default, there's no safe place to put it.
> Since AUTH_NULL seems rarely needed, it seemed best just to leave it
> off.)
RFC 2623 suggests how the server should sort the returned flavor
list. However I don't think there's a consistent algorithm the client
can use with that list to determine a good default for that mount.
So, I would argue that any client that uses the "first" or "last"
entry in that list as the mount's auth flavor is probably broken; it
should pick a sec= default for all mounts, and if it's not on the
returned list, fail the mount. That is, incidentally, what the kernel
MNT client does now.
> Anyway, we could add a second special case on the client side that
> allowed an explicit sec=null to bypass checking against the server
> list.
> I don't know who actually needs mounts with sec=null.
Or, we can make sure the server provides AUTH_NULL in the list _only_
if that flavor is specified explicitly on the export line. Otherwise,
a single entry flavor list (ie supporting only AUTH_UNIX) is probably
the best default we can provide for the reasons you state above.
It would help to provide some documenting comments to that effect in
the code, or maybe even state it in the exports(5) man page.
> And/or we could plan to put AUTH_NULL back on the server's list some
> day, depending on how widely disseminated we think the backwards mount
> behavior was....
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Chuck Lever wrote:
>
> RFC 2623 suggests how the server should sort the returned flavor
> list. However I don't think there's a consistent algorithm the client
> can use with that list to determine a good default for that mount.
> So, I would argue that any client that uses the "first" or "last"
> entry in that list as the mount's auth flavor is probably broken; it
> should pick a sec= default for all mounts, and if it's not on the
> returned list, fail the mount. That is, incidentally, what the kernel
> MNT client does now.
>
The MOUNT Version 3 protocol, associated with NFS Version 3, solves
the problem by having the response to the MNT procedure include a
list of flavors in the MNT procedure. Note that because some NFS
servers will export file systems to specific lists of clients, with
different access (read-only versus read-write), and with different
security flavors, it is possible a client might get back multiple
security flavors in the list returned in the MNT response. The use of
one flavor instead of another might imply read-only instead of read-
write access, or perhaps some other degradation of access. For this
reason, a NFS client SHOULD use the first flavor in the list that it
supports, on the assumption that the best access is provided by the
first flavor. NFS servers that support the ability to export file
systems with multiple security flavors SHOULD either present the best
accessing flavor first to the client, or leave the order under the
control of the system administrator.
It sounds pretty clear, the server SHOULD order them in some fashion and
the client SHOULD
pick the first one it supports in the list. It is not 'MUST', but if all
servers and clients follow the same
algorithm, it becomes accepted practice.
Having said that, our nfssec(5) states that a client can pick any of the
modes in the list.
But our server returns them in the order entered in the share by the admin.
The client either:
1) Uses the explicit flavor set in the mount command.
or
2) Uses the first supported one in the list.
or
3) Fails the mount.
With OpenSolaris NFSv3, there is no autonegotiation. With NFSv4, we
support the autonegotiation
as defined in the protocol.
We just went through a regression with this algorithm.