Bug#492970: (was: nfs-utils-1.1.3 released)

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

On 06/08/08 at 12:21 -0400, Chuck Lever wrote:
> On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
>> Chuck Lever <chuck.lever@oracle.com> writes:
>>> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>>>> Chuck Lever <chuck.lever@oracle.com> writes:
>>>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>>>>>
>>>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve =20
>>>>>>>> Salazar
>>>>>>>> wrote:
>>>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately=20
>>>>>>>>>> I'm having
>>>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>>>
>>>>>>>>>>  http://sourceforge.net/projects/nfs
>>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>>>
>>>>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>>>>> mount
>>>>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>>>>> file
>>>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>>>> code) is
>>>>>>>> failing.  Maybe there's some difference in the mount options?
>>>>>>>> What does
>>>>>>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>>>>>>
>>>>>>> I discovered today that I was no longer able to write to the v3
>>>>>>> mount on
>>>>>>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull o=
n
>>>>>>> the
>>>>>>> mount.  Either adding sec=3Dsys to the client's mount options or
>>>>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>>>>
>>>>>> That would do it!
>>>>>>
>>>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>>>> default
>>>>>> mount options wrong?
>>>>>
>>>>> I'm not sure I'm following this.  I can't think of a user-space
>>>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>>>
>>>>> Paul, which kernel are you running on your clients?
>>>>
>>>> Either 2.6.26 or 2.6.27-rc1+.  I'll double-check.
>>>
>>> It would be interesting if you could try both.  I suspect 2.6.26
>>> doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount
>>> parser that affect "sec=3D".
>>
>> I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
>> machine.
>>
>>> Also, enabling NFS mount debugging messages when performing the mount
>>> that eventually doesn't work would be enlightening (for me).  Either:
>>
>> I won't be around that machine for a week or so.
>>
>>>> Whichever one it was, the problem was present with 1.1.3 installed,
>>>> and
>>>> not present with 1.1.2 installed.
>>
>> Same here.
>
> Thanks for the report.
>
> In addition to the debugging mentioned above, anyone encountering this =
=20
> regression can also try a git bisect on nfs-utils (between 1.1.2 and =20
> 1.1.3).

Hi,

Some more info on this:

The problem only arises when the debian specific patch
debian/patches/05-default-use-old-mount-interface.patch is applied.
(it works fine with stock 1.1.3)

git bisecting with that patch applied shows that the first bad commit is:
commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
Author: bc Wong <bcwong@cisco.com>
Date:   Tue Mar 18 09:30:44 2008 -0400

    There were 2 things wrong with auth flavour ordering:
    - Mountd used to advertise AUTH_NULL as the first flavour on
      the list, which means that it prefers AUTH_NULL to anything
      else (as per RFC 2623 section 2.7).
    - Mount.nfs used to scan the returned list in reverse order,
      and stopping at the first AUTH_NULL or AUTH_SYS encountered.
      If a server advertises (AUTH_SYS, AUTH_NULL), it will by
      default choose AUTH_NULL and have degraded access.
   =20
    I've fixed mount.nfs to scan from the beginning. For mountd,
    it does not advertise AUTH_NULL anymore. This is necessary
    to avoid backward compatibility issue. If AUTH_NULL appears
    in the list, either the new or the old client will choose
    that over AUTH_SYS.
   =20
    Tested the server/client combination against the previous
    versions, as well as Solaris and FreeBSD.
   =20
    Signed-off-by: bc Wong <bcwong@cisco.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>
--=20
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |



--=20
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian=
.org