Bug 187370 - Unable to mount NFS V3 share where sec=none is specified
Unable to mount NFS V3 share where sec=none is specified
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: util-linux (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
:
Depends On:
Blocks: 176344 195300 210644
  Show dependency treegraph
 
Reported: 2006-03-30 11:05 EST by Eugene Kanter
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RHSA-2007-0235
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 13:18:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
snoop output of the mount process (720 bytes, text/plain)
2006-03-30 11:05 EST, Eugene Kanter
no flags Details
tcpdump -w nfsv3.cap (330 bytes, application/octet-stream)
2006-10-03 10:04 EDT, Eugene Kanter
no flags Details
"tcpdump -s 0 -w /tmp/nfsv3.cap host hostname" while running mount command (2.93 KB, application/octet-stream)
2006-10-04 16:02 EDT, Eugene Kanter
no flags Details
Proposed patch (606 bytes, patch)
2006-10-12 13:20 EDT, Peter Staubach
no flags Details | Diff

  None (edit)
Description Eugene Kanter 2006-03-30 11:05:03 EST
Description of problem:

unable to mount NFS V3 share from Solaris when sec=none is used.

Version-Release number of selected component (if applicable):

nfs-utils-1.0.6-65.EL4

How reproducible:

always

Steps to Reproduce:
1. create a share with following entry in /etc/dfs/dfstab

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

2.

issue a mount command from RHEL

mount server:/path/to/share /mnt
  
Actual results:

mount: server:/path/to/share failed, security flavor not supported

Expected results:

no errors.

Additional info:

mount -o nfsvers=2 server:/path/to/share /mnt

works.

Attached is snoop output of the mount process.
Comment 1 Eugene Kanter 2006-03-30 11:05:04 EST
Created attachment 127057 [details]
snoop output of the mount process
Comment 2 Peter Staubach 2006-07-26 11:40:31 EDT
Could the raw snoop capture file be attached, please?  That would be
much more helpful than just the terse output.
Comment 3 RHEL Product and Program Management 2006-08-18 12:20:46 EDT
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.
Comment 5 Peter Staubach 2006-09-20 16:06:17 EDT
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.
Comment 6 Eugene Kanter 2006-09-29 17:18:24 EDT
what is the command for raw snoop or tcpdump capture?
Comment 7 Peter Staubach 2006-10-02 09:05:30 EDT
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.
Comment 8 Eugene Kanter 2006-10-03 10:02:19 EDT
I was using tcpdump -w and did

ls /net/solarishost/exported/folder

Comment 9 Eugene Kanter 2006-10-03 10:04:05 EDT
Created attachment 137650 [details]
tcpdump -w nfsv3.cap
Comment 10 Peter Staubach 2006-10-03 10:31:16 EDT
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.
Comment 11 Eugene Kanter 2006-10-04 16:00:28 EDT
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
Comment 12 Eugene Kanter 2006-10-04 16:02:45 EDT
Created attachment 137768 [details]
"tcpdump -s 0 -w /tmp/nfsv3.cap host hostname" while running mount command
Comment 13 Peter Staubach 2006-10-04 16:27:57 EDT
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?
Comment 14 Eugene Kanter 2006-10-06 14:39:52 EDT
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. 
Comment 15 Peter Staubach 2006-10-12 13:15:14 EDT
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.
Comment 16 Peter Staubach 2006-10-12 13:20:14 EDT
Created attachment 138345 [details]
Proposed patch
Comment 17 Peter Staubach 2006-10-12 13:23:02 EDT
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.
Comment 18 Steve Dickson 2006-10-13 13:38:33 EDT
Fixed in util-linux-2.12a-16.EL4.22
Comment 21 Ben Levenson 2007-03-26 23:21:18 EDT
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.
Comment 23 Red Hat Bugzilla 2007-05-01 13:18:00 EDT
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

Note You need to log in before you can comment on or make changes to this bug.