RFS is by far better that NFS!

Jim Logan logan at inpnms.UUCP
Sat Dec 16 03:20:49 AEST 1989


In article <BITBUG.89Dec14220256 at lonewolf.sun.com>
bitbug at lonewolf.sun.com (James Buster) writes:
# In article <218 at inpnms.UUCP> logan at inpnms.UUCP (Jim Logan) writes:
# > We all have 386's on our desks running RFS and have enjoyed
# > having root access to our machines, but not on the server.  From
# > what we have read, this is not possible under NFS.  Is this true?  
# > 
# > We are in the process of changing over to NFS from RFS under
# > 386/ix in order to use the large disks on our MV 40000 running
# > DG/UX.  
# > 
# > Is seems that the only way to prevent root access on the server
# > under NFS is by appointing one person as the administrator.  It
# > doesn't make much sense to have one person responsible for an
# > entire network of 386's.  He would have to be responsible for
# > changing the mode of files, killing processes, etc.  No one
# > around here wants grunt work like this.
# > 
# > Is this really a security issue, or are we misinformed?  Is
# > there a solution?
# 
# I'm not sure what question you are asking? Do you mean,
# does a root user on the client have normal root file access
# permissions on file systems mounted from the server, or is
# a root user on the client able to log into the server as root?

No, I was a bit too vague in my original posting.  Let me
rephrase in more detail.  

Given a server with user IDs 101, 102, and 103, and a client
having only UID 101, anyone with root access on the client
can access files owned by UIDs 102 and 103.  

This is a big security hole if it is true.  As I understand it,
there is no way to have a user on the server that is unmappable
on a client.  For instance, we have the user "scm" (source-code
management) on the host that owns the files that we release. 
These files cannot (and should not) be modified in any way by a
user on a client, since "scm" maps to a bogus UID on a client
under RFS.  We simply want the same, or equivalent, functionality
from NFS.  Can it be done?   

-- 
James Logan                       UUCP: uunet!inpnms!logan
Data General Telecommunications   Inet: logan%inpnms at uunet.uu.net
(301) 590-3069



More information about the Comp.unix.i386 mailing list