🚀 go-pugleaf

In article <18152@umd5.umd.edu> matthews@oberon.umd.edu (Mike Matthews)  
writes:
#Does anyone have any ideas as to why I'm getting authentication errors  
when
#trying to edit data served by another machine, when that domain's root
#password is empty (it isn't always empty, just testing)?
#

If there is not a "root" account on a level in the Netinfo structure, then  
that level can only be modified on the machine that serves it.  To solve  
this problem, add a root user to the particular level you want to be able  
to change from clients (i.e, in your case, add a "root" user to the /  
domain).  The root users in these domains can have different passwords if  
you like and can make for added security since you will have to supply a  
password to make any changes to that particular domain.  This would me  
that if someone got root on your server, they would only be able to screw  
with the local netinfo domain on that server (unless all your root  
passwords in Netinfo are the same!)...

#Here's the exact situation.  Voyager is our two level NetInfo server, so  
it
#serves / and /voyager.  (It's a NeXTcube, this is all NeXTstep 3.0.)
#Pioneer, a color station, serves /pioneer.
#
#Pioneer can not authenticate itself to / or /voyager.  It just can't.  At
#first I thought it was some sort of trusted_networks glitch, but we don't  
use
#trusted_networks.  Then I thought it might've been a machine/IP
#address/ethernet address mismatch, but all the relevant data seemed fine.

I would suggest that you use trusted_networks.  Otherwise anyone can snarf  
any of your netinfo data by using tags.
 
#------
#Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
#------
#One of the saddest lessons of history is this:  If we've been bamboozled
#long enough, we tend to reject any evidence of the bamboozle.  We're no
#longer interested in finding out the truth.  The bamboozle has captured
#us.  it is simply too painful to acknowledge -- even to ourselves -- that
#we've been so credulous.  (So the old bamboozles tend to persist as the
#new bamboozles rise.)
#-- Carl Sagan, "The Fine Art of Baloney Detection," Parade, February 1,  
1987

--
Paul S. Sears                *  sears@uh.edu (NeXT Mail OK)
The University of Houston    *  suggestions@tree.egr.uh.edu (NeXT
Engineering Computing Center *  comments, complaints, questions)
NeXT System Administration   *  DoD#1967 '83 NightHawk 650SC 
          >>> SSI Diving Certification #755020059 <<<
"Programming is like sex: One mistake and you support it a lifetime."

In article <1k3lgmINNq80@menudo.uh.edu> sears@uh.edu writes:
>If there is not a "root" account on a level in the Netinfo structure, then  
>that level can only be modified on the machine that serves it.

True.  The problem turned out to be many uid 0 accounts (a field account set
up for class use, and somehow sundiag and sysdiag got there too....).
Getting rid of all the other uid 0 accounts solved the problem.  Jeff Kight
suggested the fix.

>The root users in these domains can have different passwords if  
>you like and can make for added security since you will have to supply a  
>password to make any changes to that particular domain.  This would me  
>that if someone got root on your server, they would only be able to screw  
>with the local netinfo domain on that server (unless all your root  
>passwords in Netinfo are the same!)...

Um, not quite.  Root on the local machine can modify whatever it wishes on
that machine.  NetInfo checks the incoming port number, and if it's less than
1024, it's considered trusted.  If you are not root, yes, you need to enter
the appropriate root password (with niutil -p or the NetInfo authentication
panel with the GUIs).

>I would suggest that you use trusted_networks.  Otherwise anyone can snarf  
>any of your netinfo data by using tags.

Normally I would but these are on their own network, with no connection to
anything else.

>Paul S. Sears
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
"A fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
-- Mandelbrot, _The Fractal Geometry of Nature_