RFS is by far better that NFS!

~XT6561110~Frank McGee~C23~L25~6326~ fmcgee at cuuxb.ATT.COM
Sat Dec 23 06:43:26 AEST 1989


In article <957 at ursa-major.SPDCC.COM> dyer at ursa-major.spdcc.COM (Steve Dyer) writes:
>In article <1989Dec19.195321.3431 at ddsw1.MCS.COM> karl at mcs.MCS.COM (Karl Denninger) writes:
>>
>>The problem we have is that we have a physically secure network.  Thus, we
>>WANT root to really be root -- on all filesystems.  Allowing this lets us
>>put one big Exabyte tape drive on the network and back up everything.  It
>>allows us many other conveniences as well.
>>With 386/ix NFS, none of this is possible -- unless I want to write a tape
>>server.  Ugh.
>
>Can't you patch the value of the variable "nobody" in your ISC kernel?
>
>Most Sun-derived NFS ports use the value of the integer variable "nobody"
>as the UID to map root to.  If you use "adb" or something you hack
>yourself to change the value of "nobody" to 0, you should be all set.
>
>I'm not an ISC user, but this is almost always consistent across most
>implementations.

I've been following this discussion, and maybe something's eluded me
or there's a serious security issue here.  On RFS, I can map user's
out based upon which server they are on.  For instance, I can say "user
fmcgee on cuuxb can't access /src, but user fmcgee on otherhost
can".  This provides security down to the unique uid, both the login
id (ascii) and uid (integer).

It seems to me that NFS only provides security at the uid (integer)
level.  To keep people out of my files, I need to have a unique uid.

Not so trivial on a network with several thousand users and several
hundred hosts, of which I only control 20 or 30 hosts.

Or did I miss something ?  I agree and understand that "root" can be
made secure or unsecure as needed.

Did I miss something ?

BTW, I'm not NFS bashing; there are some features of it that I like
and that I feel it does better than RFS (such as portability to
non-AT&T unixes).

-- 
Frank McGee, AT&T
Tier 3 Complementary Channel Sales Support
attmail!fmcgee



More information about the Comp.unix.i386 mailing list