Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!ziploc!eps
From: eps@toaster.SFSU.EDU (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: Unix `w' command not working
Message-ID: <1378@toaster.SFSU.EDU>
Date: 2 Mar 91 06:18:37 GMT
References: <1367@toaster.SFSU.EDU> <1991Feb27.172635.132@gacvx2.gac.edu> <1991Mar1.010704.25496@mp.cs.niu.edu>
Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
Organization: San Francisco State University
Lines: 72

In article <1991Feb27.172635.132@gacvx2.gac.edu> dan@gacvx2.gac.edu writes:
>I have the same problem on netboot clients.  "w" and "netstat" return "No
>namelist" programs like "monitor" don't work either.  It worked under 0.8 and
>0.9.  It quit when I upgraded to 1.0.  I still see the problem on 2.0.

Interesting.  I saw that problem in 0.9 and 1.0, but *not* on 2.0.

>                                                                        I was
>told that this is due to NFS maps the UID of root to -1 so that it does not
>have the same abilities on the network file system as it would on a local file
>system.  The documentation (on-line I think) for 1.0 mentioned a patch that
>could be entered into the kernal using 'adb' that would give root UID 0 on the
>network file systems.  I was not able to get 'adb' to work on 1.0, and NeXT
>did not recommend the patch.

I think you're extremely confused.  /etc/exports controls who can
perform NFS mounts, and what access is permitted.  The default
setting has uids traverse the network, except "unknown users"
and those claiming to be root instead operate with the permissions
of "nobody"--uid -2.

There are two NFS options that modify that behavior.  The first
is root.  This takes a colon-separated list of hostnames for
which uid 0 should be honored.  The second is anon--this alters
the the uid "unknown" access is granted.  There are no kernel
patches involved.


In article <1991Mar1.010704.25496@mp.cs.niu.edu> bennett@mp.cs.niu.edu
	(Scott Bennett) writes:
>                                 The remapping is done for a very good
>reason and should not be defeated.  If UID 0 *were* maintained in such
>a situation, anyone who had the root password for a machine served by
>your machine would have unrestricted access to anything on your machine.
>Given that anyone with a workstation--and keep in mind that workstations
>are commonly served by other machines via NFS--can boot a workstation
>in single-user mode, honoring UID 0 across an NFS connection would 
>effectively eliminate *all* security on the serving system and any other
>machines served by it.

You're still not protected from a client masquerading as any
other uid and getting owner access to any user's files.  What's
more valuable?  System software that can be restored from
original distribution media?  Or personal work you "forgot" to
back up?  The bottom line is that you have to trust _any_
workstation that does NFS mounts.  Exporting directories read-
only when feasible helps.  ROM Passwords help (to the extent
that they deter the less-skilled crackers).  Telling NeXT you
want to see "Secure NFS" a la SunOS in a future release helps.

When is it necessary for clients to have root access to / on the
server?  As far as I can tell, the only thing that breaks without
it is the Guided Tour demo.  I'm a little worried about having it
on NetBoot clients; it does [the equivalent of] a
	dwrite loginwindow DefaultUser NextTour
as root on the server machine.  Can you say "race condition?"

The really insecure option setting is anon=0 ("anybody I don't
know gets root access").  _Network and System Administration_
says you need to use this to run the braindead UserManager
application "on any machine on the network."  (Then it asks
for root's password... what's the POINT???)  Stupid, stupid,
stupid.

This whole GUI mess ("we must hide command-line interfaces at all
costs") is getting out of hand.  Hey sysadmin wannabes: it's
really ok to hit Command-Shift-U to run UserMangler remotely with
-NXHost.  PublicWindowServer on a client is a heck of a lot less
risky than open root access on the server.  You heard it here
first.

					-=EPS=-