Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Newsgroups: comp.sys.apollo
Subject: Re: Registry problems AGAIN
Message-ID: <1990Oct26.173919.15324@alchemy.chem.utoronto.ca>
Date: 26 Oct 90 17:39:19 GMT
References: <9010260420.AA11366@pan.ssec.honeywell.com>
Organization: University of Toronto Chemistry Department
Lines: 32

In article <9010260420.AA11366@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:
>> In article <9010250649.AA01789@vlsi-mentor.jpl.nasa.gov> root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) writes:
>> >What is this? I am logged in as 'root' and edrgy tells me I am
>> >"not authorized to perform operation"? 
>
>2 Yes, there is a FEATURE (it's documented) to allow root.%.% AND %.locksmith.%
>  to muck with the registries, even if they aren't the owner, IFF they are
>  logged onto the node that holds the master registry.  Even if it weren't
>  documented, I'd consider it a feature.  What do you do when you hose up
>  your owner-of-registry account?  WHat happens if all the sys-admins decide
>  to quit?  Or die?
>3 The reason that I have heard for the original problem is that you must have
>  logged in to the window/pad/terminal/console/whatever as the owner-of-
>  registry.  In other words, if you do a 'crp -on //node -me' and try from 
>  there, it won't work, since your password hasn't been truly validated when
>  you CRPed over.  I haven't verified this, but it seems to match my earlier
>  hassles with registry modifying, and I haven't had any since.

You are correct - you must login directly to the master registry node,
then certain extra commands will work.
We APR'ed this over a year ago - it may be a feature, but has no use
I can see. If you are root on any Apollo system, you can destroy
anything you like on any Apollo system reachable by NCS (try 'rm -r //* &'
from a UNIX shell, wait a while, and see what's left), so I see no
point in protecting certain registry operations from remote root access
when the remote root could just delete the entire operating system
including the /sys/registry tree which edrgy is trying to protect
right out from under you.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775