Bug 187370

Created attachment 127057 [details]
snoop output of the mount process

Could the raw snoop capture file be attached, please?  That would be
much more helpful than just the terse output.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

This does not appear to be a bug.  The NFSv3 client does not support
AUTH_NONE as a valid authentication flavor.  In this case, the server
is returning AUTH_NONE as the only valid authentication flavor.  Since
the client does not support it, an error is generated.

The NFSv2 case appears to work because it causes the file system to
be mounted.  It does not know that the server has specified that
AUTH_NONE should be used.  However, it generates AUTH_SYS over the
wire, which the server appears to honor.  If anything this is a bug
in the Solaris NFS server because it does not seem to be respecting
the security flavor specified by the share command.

Without some more information, I will need to close this report as
NOTABUG.

what is the command for raw snoop or tcpdump capture?

There are several commands which can be used, but --

On the Solaris server, use the snoop(1M) command:

snoop -o /tmp/snoop.cap host <name_of_client>

and then attach //tmp/snoop.cap to this bugzilla.

I was using tcpdump -w and did

ls /net/solarishost/exported/folder

Created attachment 137650 [details]
tcpdump -w nfsv3.cap

Perhaps I am not explaining what I need clearly enough.  The capture
file which was previously attached is not useful because 1) it only
captured 3 packets and 2) those packets were truncated.  If tcpdump
is to be used, then the option, "-s 0" must be used in order to capture
the entire packet.  I suggested using snoop(1M) from the server
because I knew that snoop does not require any special flags to
capture the entire packet.  Neither does tethereal from Linux.

After performing the capture, please examine the capture file using
either ethereal or wireshark, whichever you've got, to be sure that
it contains whole packets and all of the packets, including at least
MOUNT protocol traffic and any NFS traffic, if there is any.

console 1:
tcpdump -s 0 -w /tmp/nfsv3.cap host hostname
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
30 packets captured
73 packets received by filter
0 packets dropped by kernel
console 2:
mount hostname:/share /mnt
mount: hostname:/share failed, security flavor not supported

Created attachment 137768 [details]
"tcpdump -s 0 -w /tmp/nfsv3.cap host hostname" while running mount command

Thanx!  That is the the capture that I was looking for.

This is as I described earlier.  The Solaris NFS server returns only
AUTH_NONE in the list of supported authentication flavors.  The Linux
NFSv3 client does not support AUTH_NONE, so fails the mount.

What is the purpose of exporting the file system from the server using
only AUTH_NONE?

My understanding is that it forces specified UID on all files created regardless
which user created them. There is a deamon runing as UID and it must have write
access to files created on the share.

share -F nfs -o sec=none,rw,anon=UID /path/to/share

                sec=none
                      If the option sec=none  is  specified  when
                      the  client  uses   AUTH_NONE,  or  if  the
                      client uses a security mode that is not one
                      that  the  file system is shared with, then
                      the  credential  of  each  NFS  request  is
                      treated   as   unauthenticated.   See   the
                      anon=uid option for a  description  of  how
                      unauthenticated requests are handled.
                anon=uid
                      Set  uid to be the  effective  user  ID  of
                      unknown  users.  By  default, unknown users
                      are given the effective user ID UID_NOBODY.
                      If  uid is set to -1, access is denied.


Similar to a force_user directive in smb.conf:

       force_user (S)
              This specifies a UNIX user name that will  be  assigned  as  the
              default  user  for all users connecting to this service. This is
              useful for sharing files. 

Okay.  Thanx for the information from the Solaris man pages.

It does seem like the Linux NFS client could/should support AUTH_NONE in
much the same fashion as does Solaris.

Created attachment 138345 [details]
Proposed patch

The attached patch modifies the mount process on the client to use
the currently specified authentication flavor if the server has
exported the file system to AUTH_NONE.

Fixed in util-linux-2.12a-16.EL4.22

This fix is available in the latest RHEL-4.5 Beta.  If the customer is in
a position to test the beta, please ask for testing feedback. Thanks.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0235.html