root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) (10/25/90)
What is this? I am logged in as 'root' and edrgy tells me I am
"not authorized to perform operation"?
According to the properties, my SID *owns* the registry and the
files the registry is based on. What gives?
----
Dave Hayes dave@vlsi-mentor.jpl.nasa.gov
{ucbvax,ames}!elroy!vlsi-mentor!dave
"Attempt to find truth by realizing that it will generally find YOU."lau@kings.wharton.upenn.edu (Yan K. Lau) (10/26/90)
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"? > >According to the properties, my SID *owns* the registry and the >files the registry is based on. What gives? > >---- >Dave Hayes dave@vlsi-mentor.jpl.nasa.gov > {ucbvax,ames}!elroy!vlsi-mentor!dave >"Attempt to find truth by realizing that it will generally find YOU." This is what I learned. It may not apply to your situation. Following the example instructions in creating registries, I set up them to be "owned" by %.sys_admin.%. This was done during the cvtrgy (converting 9.7 registries) and not the same as the acls of the directories. However, %.sys_admin.% is not the same as root.%.% which is different since root usually has access to everything. It turns out that if you are logged on as root on the machine with the master registries, you can perform add/changes, etc. anyway. This is either a feature or a bug. However, if you are logged onto another machine, then the %.sys_admin.% is enforced and you are not allowed to perform operations even if you are root. My solution: I created root.sys_admin.% so I can (if I have to) edrgy from any machine. I haven't actually tried edrgy as for example, lau.sys_admin so I don't know if that works. Hope this helps. Yan. )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ -Sheenaphile- 128.91.11.233 University of Pennsylvania /\ God/Goddess/All that is -- the source of love, light and inspiration!
nazgul@alphalpha.com (Kee Hinckley) (10/26/90)
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"? Are you actually logged in (/bin/login) or just su'd? It cares. -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (10/26/90)
<<forwarded message>> > 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"? > > > >According to the properties, my SID *owns* the registry and the > >files the registry is based on. What gives? > > This is what I learned. It may not apply to your situation. Following the > example instructions in creating registries, I set up them to be "owned" by > %.sys_admin.%. This was done during the cvtrgy (converting 9.7 registries) > and not the same as the acls of the directories. > > However, %.sys_admin.% is not the same as root.%.% which is different since > root usually has access to everything. It turns out that if you are logged > on as root on the machine with the master registries, you can perform > add/changes, etc. anyway. This is either a feature or a bug. However, > if you are logged onto another machine, then the %.sys_admin.% is enforced > and you are not allowed to perform operations even if you are root. 1 Of course %.sys_admin.% is not the same as root.%.% ! The sys_admin group is just another group. Normally, they have some added ACLs, but it's totally up to _you_ as the implementor of the system. In fact, I don't believe that %.sys_admin.% even needs to exist, at sr10! 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. John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (10/27/90)
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
mth@cci632.UUCP (Michael Hickman) (10/27/90)
We have a situation here where my cohort created a couple of
accounts (never having done it before) and for a person entry
named 'joe' set the owner as joe.%.%. He then couldn't
create the account 'joe.eng.none' ("not authorized to perform
operation" - sound familiar) because an account named "joe" was
the only account authorized to mess with the person "joe"!!
Once I returned from vacation, I logged in as root and tried
to delete the person 'joe', and got the message "not authorized
to perform operation". AS ROOT!!!
The only way I found to get a valid account for person "joe"
was to use import_passwd to import an account named "joe". This
allowed me to rename the original "joe" to "bogus", but now I have
a person entry named "bogus" that is owned by an account "bogus.%.%".
Why can't I delete this entry as root??
------------------------
Michael T. Hickman
Computer Consoles Inc.
Rochester, NY (716) 482-5000 x2913
mth@cci.com
------------------------thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (10/28/90)
> We have a situation here where my cohort created a couple of > accounts (never having done it before) and for a person entry > named 'joe' set the owner as joe.%.%. He then couldn't > create the account 'joe.eng.none' ("not authorized to perform > operation" - sound familiar) because an account named "joe" was > the only account authorized to mess with the person "joe"!! > > Once I returned from vacation, I logged in as root and tried > to delete the person 'joe', and got the message "not authorized > to perform operation". AS ROOT!!! > > The only way I found to get a valid account for person "joe" > was to use import_passwd to import an account named "joe". This > allowed me to rename the original "joe" to "bogus", but now I have > a person entry named "bogus" that is owned by an account "bogus.%.%". > > Why can't I delete this entry as root?? Because root doesn't own the entry!!! Unlike Unix, Domain/OS doesn't recognize GOD as the owner of all things. As was mentioned in the previous postings, you _can_ break the security by logging on to the master-registry-server's node as 'root' or '%.locksmith.%' and editing/deleting it there. This is the 'back door' save-a?s mechanism to get things corrected once you hose them up. P.S. If you don't know where your master registry node is, see your system administrator, or use /etc/rgy_admin. John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
mmuegel@camdev.comm.mot.com (Mike "Happy" Muegel) (10/29/90)
In article <1990Oct26.173919.15324@alchemy.chem.utoronto.ca> Mike Peterson writes: > ... 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. Under SR10+ you can protect nodes from remote root access via the '/etc/lprotect' command. By using it, you can make it so that remote roots (those not logged onto the node remotely or locally) can have read-only access to objects or no access at all. If you then modify the /etc/rgy/passwd_overide file you can extablish different paswords for a given account (such as a root account). Thus, you will have limited root login privlidges to this node to those roots that you wish to have access. You have to do this also since someone could just crp/rlogin onto the secure node as joe-user then still do an su root-whatever. We were going to use this at our site to secure some super-secret stuff but eventually decided against it because it made remote-software installation a pain. -Mike -- +-----------------------------------------------------------------------------+ | Mike Muegel | Internet: mmuegel@mot.com | | Software Tools Engineer | UUCP: uunet!motcid!muegel | | Fort Worth Research and Design Center | Voice: (817) 232-6623 | | Cellular Infrastructure Group | Fax: (817) 232-6030 | | Radio Telephone and Systems Group | Mail: 5555 North Beach St. | | Motorola, Inc. | Fort Worth, TX 76137 | +-----------------------------------------------------------------------------+
root@evtprp0b.UUCP (Eric T. Smith) (10/30/90)
In article <9010250649.AA01789@vlsi-mentor.jpl.nasa.gov> you write: >What is this? I am logged in as 'root' and edrgy tells me I am >"not authorized to perform operation"? > >According to the properties, my SID *owns* the registry and the >files the registry is based on. What gives? > If you are running the cvtrgy program to convert from SR9 to SR10 and the SR9 registry is writable this is your problem: 1) The SR10 registry has some internal verification code it uses to denote the "owner" of the registry. You set this with the -owner option of the cvtrgy program. 2) Every time you run the cvtrgy program this internal number is changed, even though the "owner" is the same person, group, org. 3) If you log in as root and then run cvtrgy you are the root user with the old verification code, not the new one, and will get the error message if you try to change things with rgy_admin. 4) The cure is to log in again, or crp on without the -me, or run login in a window. This makes you the root with the new verification key and works fine... If you're not running cvtrgy from 9 to 10 you may have a problem with the key resulting from SR10.1, if you had/have nodes at 10.1 you might want to call Apollo/HP and talk to them about it. -- |----------------------------------------------------------------| |Eric Smith (206) 342-9681 (wk) | |Boeing Computer Services ....uunet!bcstec!evtprp0b!root | |M/S 03-87, P.O. Box 24346, Seattle, WA 98124-0346 | |----------------------------------------------------------------| |The answer is 42... | | --but-- | | What was the question? | |----------------------------------------------------------------| | Needless to say my opinions are MINE, not Boeings... | |----------------------------------------------------------------|
austin@METO.UMD.EDU (Austin L. Conaty) (10/31/90)
It is sort of funnnnny that a root crp'd on has limited rights when joe schmoe can walk in type shut, ex invol option 1, and really ruin your day.
rees@pisa.ifs.umich.edu (Jim Rees) (10/31/90)
In article <9010302021.AB01586@meto.UMD.EDU>, austin@METO.UMD.EDU (Austin L. Conaty) writes:
It is sort of funnnnny that a root crp'd on has limited
rights when joe schmoe can walk in type shut, ex invol
option 1, and really ruin your day.
That's not funny at all, that's the way it should be. Joe can always walk
in with an arm full of explosives and ruin more than just the software. If
you want the machine to be secure, you have to secure it from physical
access as well as network access.
I think there is some software option to prevent random shutdowns for those
fanatics who try to allow physical access while maintaining physical
security.krowitz@RICHTER.MIT.EDU (David Krowitz) (10/31/90)
Actually, there is a mechanism that has been added to prevent users from using the DM "shut" command. It is a new feature of SR10.3. If the file `node_data/dm_display/shut_lock exists, and you have access rights to the file, then the DM will execute your "shut" or "ex" command. Otherwise, it will ignore you. Note that if the file exists, you must login prior to attempting the "shut" or "ex" commands. Also note that, as Jim pointed out, this is a silly waste of time if your workstations are not physically secure. Absolutely anyone can set the service mode switch to "service" and then press the reset button. You can probably even train your pet schnauzer to do it (larger dogs, however, will have trouble with those small buttons -:) ). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)