Solaris 2.6 NFS bug

Solaris 2.6 NFS bug

Post by Duncan Philli » Wed, 14 Jan 1998 04:00:00



We are having a problem with Solaris 2.6 hosts and NFS.

When a 2.6 host (logic) exports a filesystem with root permissions
to a second host (catalina) using catalinas A record name, catalina
does have root permissions on logics filesystem. However, if the
filesystem is exported to catalina by catalinas CNAME, root on
catalina gets a permission denied error message when root actions
are attempted.

If the filesystem is exported to catalinas CNAME and permissions are
changed on the exported filesystem to 777, root on catalina can
create a file (of course) but the file owner is nobody.

This happens with both automounted and manually mounted filesystems.

We also tested and found that it does not matter if the mounting host
is 2.5.1 or 2.6 as long as the server is 2.6.
--

Office of Academic Computing

University of California, Irvine

 
 
 

Solaris 2.6 NFS bug

Post by David William » Thu, 15 Jan 1998 04:00:00



halfdome.acs.uci.edu> writes

Quote:>We are having a problem with Solaris 2.6 hosts and NFS.

>When a 2.6 host (logic) exports a filesystem with root permissions
>to a second host (catalina) using catalinas A record name, catalina
>does have root permissions on logics filesystem. However, if the
>filesystem is exported to catalina by catalinas CNAME, root on
>catalina gets a permission denied error message when root actions
>are attempted.

>If the filesystem is exported to catalinas CNAME and permissions are
>changed on the exported filesystem to 777, root on catalina can
>create a file (of course) but the file owner is nobody.

  This is a normal part of NFS, user root on the client is mapped to
  user nobody on the server. It is a part of the definition of NFS.
  Supposed to increase security. Otherwise anyone who can mount an
  NFS partition could

  a) mount it as root
  b) create a setuid root shell
  c) login to the server and run the setuid root shell.

Quote:>This happens with both automounted and manually mounted filesystems.

>We also tested and found that it does not matter if the mounting host
>is 2.5.1 or 2.6 as long as the server is 2.6.

--
David Williams

Maintainer of the Informix FAQ
 Primary site (Beta Version)  http://www.smooth1.demon.co.uk
 Official site                http://www.iiug.org/techinfo/faq/faq_top.html

I see you standin', Standin' on your own, It's such a lonely place for you, For
you to be If you need a shoulder, Or if you need a friend, I'll be here
standing, Until the bitter end...
So don't chastise me Or think I, I mean you harm...
All I ever wanted Was for you To know that I care

 
 
 

Solaris 2.6 NFS bug

Post by Duncan Phillip » Thu, 15 Jan 1998 04:00:00



>   This is a normal part of NFS, user root on the client is mapped to
>   user nobody on the server. It is a part of the definition of NFS.
>   Supposed to increase security. Otherwise anyone who can mount an
>   NFS partition could

I'm aware of this. However, we have the problem when we export the
filesystem with root permissions to the client.

In our case, the client should be able to do things like create files on the
server's filesystem. It can if export is to the client's A record name but not
if it's to the client's CNAME. Either way, it is able to mount the filesystem.

--
Duncan Phillips

 
 
 

Solaris 2.6 NFS bug

Post by Logan Sh » Thu, 15 Jan 1998 04:00:00




>We are having a problem with Solaris 2.6 hosts and NFS.

>When a 2.6 host (logic) exports a filesystem with root permissions
>to a second host (catalina) using catalinas A record name, catalina
>does have root permissions on logics filesystem. However, if the
>filesystem is exported to catalina by catalinas CNAME, root on
>catalina gets a permission denied error message when root actions
>are attempted.

>If the filesystem is exported to catalinas CNAME and permissions are
>changed on the exported filesystem to 777, root on catalina can
>create a file (of course) but the file owner is nobody.

>This happens with both automounted and manually mounted filesystems.

>We also tested and found that it does not matter if the mounting host
>is 2.5.1 or 2.6 as long as the server is 2.6.

You haven't specified whether you're using read-write or root
permission for host-based mounting permission, i.e. with "share".
Quoting the relevant line from /etc/dfs/sharetab would be helpful.

Plus, isn't exporting to a CNAME somewhat dangerous anyway, since the
mountd is going to go through all kinds of elaborate checks when a
remote system makes a mount request?  O.K., maybe not elaborate checks,
but it's going to at some point reverse-resolve the IP address into a
hostname and check that against your export permissions, as well as
resolving the hostname into an IP address to make sure everything is
O.K. from that end of things as well.

I don't really know the full behavior of mountd, but it presumably
must at least do the step where the exported hostname is compared
to what is gotten by reverse resolving the IP address whence the
mount request came, since it says this in the manual page:

     Some routines  that  compare  hostnames  use  case-sensitive
     string  comparisons;  some  do  not.  If an incoming request
     fails, verify that the case of the hostname in the  file  to
     be  parsed  matches the case of the hostname called for, and
     attempt the request again.

(Right?)

In other words, I'm questioning whether exporting to CNAMEs is a good
idea in the first place if you want to maintain compatibility with the
various versions of various operating systems.  Besides which, CNAMEs
are not aliases, they are pointers to the *canonical* name of a host.
They are not intended to be used as substitute names.  They are
intended to be used to allow hosts which don't have the new (canonical)
name to still contact the host until they can be fixed.

Personally, I recommend using additional "A" records instead of CNAMEs
in most cases, although that can be tricky too if you need to worry
about reverse resolution.  Another approach is to actually use a
separate IP address and an alias on the interface, although that
approach has its problems too (replies to network requests can come
from a "different host" altogether!).

  - Logan