Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) Newsgroups: comp.sys.apollo Subject: re: crp does not work + passwd wrong type Message-ID: <9105101422.AA24078@pan.ssec.honeywell.com> Date: 10 May 91 14:22:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 85 > I have problems with crp on a node that is also a "cell", > what means that it has its own private glbd. It's the only > node in the cell too. > What I get when I do "crp -login ..." is : > > "Unable to set sid - no right to perform operation > ( from O/S, ACL manager )" and "? (spmlogin), > no right to perform operation ( OS/ ACL manager )". > > If I try a slightly different syntax "crp -me" I get : > > "?(spmlogin) Unable to set project list - no right ..." > > I have checked the passwd and it was of type "unstruct", so I > first tried to fix this by restarting the rgyd, even the glbd > and all the stuff to create a cell ( Managing NCS, Procedure 5-1 ), > but it did not work. I also remoded /etc/passwd and thought the > rgyd would create a new one, but that did not work too. > > The /sys/registry dbase seems ok. The problem originated when > I had to re-install the node and made a copy of the disk with cpt, > but restored it with tar !! Then problems started with corrupted > file types, but edrgy seemed ok, so I did not pay attention anymore > to the registries. But a few weeks later I noticed that omniback > had not performed a backup of the node since a month or so. Big > panic ! ( Omniback tries to do a crp on every node in order to start > a backup process ) This is probably one of 2 things: 1) The ACLs are set wrong/weird on the crp?? devices and/or the `node_data/proc_dir directory. Check them both out, but my bet is... 2) You munged the protected login subsystem. Apollo has things that are similar to setuid rights in a thing called a protected subsystem. You can have programs/data that are part of the subsystem, and the programs will make calls to raise their access before making changes to the protected data elements. The login stuff comes under this category, back from before the sr10 registry was around. Here's (at least some of) what you need to have : -- jt > acl /sys/subsys/login -- Acl for /sys/subsys/login: -- Subsystem login manager -- Required entries -- root.%.% pr-x- -- %.sys_admin.% -r-x- -- %.%.none [ignored] -- %.%.% -r-x- -- jt > acl /com/login -- Acl for /com/login: -- Subsystem login manager -- Required entries -- root.%.% pr-x- -- %.sys_admin.% -r-x- -- %.%.none [ignored] -- %.%.% -r-x- -- jt > acl /sys/spm/spmlogin -- Acl for /sys/spm/spmlogin: -- Subsystem login manager -- Required entries -- root.%.% pr-x- -- %.sys_admin.% -r-x- -- %.%.none [ignored] -- %.%.% -r-x- -- Extended entry rights mask: ----- If the /sys/subsys/login file is missing, copy it over from another node. You can make things be login managers/data with the 'subs' command, but I've found it easier to just become root and ACL the elements from a known good copy (e.g. acl //bad/sys/spm/spmlogin //good/sys/spm/spmlogin) Do a HELP on protection/proected_subs to find out more. Hope this helps... -- jt -- John Thompson (I'M ENGAGED!!!!) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com A pessimist sees the tunnel. An optimist sees the light at the end of the tunnel. The realist sees the tunnel, the light at the end of the tunnel, and realizes that it's an oncoming train.