root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) (08/28/90)
Does ANYONE on this list know how to use edrgy's ADOPT command to restore the person name <=> UID relationships that the registry normally knows about? What I need is a way to print the acl UID's of a file and plug that number into the ADOPT command so that person X's acls will be ok. ---- Dave Hayes dave@vlsi-mentor.jpl.nasa.gov dave%vlsi-mentor@jpl-mil.jpl.nasa.gov "The word 'choice' is a fraud when one is taught what to choose."
rees@pisa.ifs.umich.edu (Jim Rees) (08/28/90)
In article <9008272051.AA01513@vlsi-mentor.jpl.nasa.gov>, root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) writes: Does ANYONE on this list know how to use edrgy's ADOPT command to restore the person name <=> UID relationships that the registry normally knows about? What I need is a way to print the acl UID's of a file and plug that number into the ADOPT command so that person X's acls will be ok. Adopt works as advertised. The trick is to get the uid of the person who owns the file. I don't know of any released program that will give this to you. Here's a program that will. Unfortunately I can't give out the include files it uses, since they are Apollo licensed, but anyone who is sufficiently determined ought to be able to determine the layout of the file_$attributes_t struct. As always, use unreleased calls at your own risk. This program could break at any future release of Domain/OS, and you would have no one to blame but yourself. Note the use of ErrMsg(). This is a useful little routine all by itself. # The rest of this file is a shell script which will extract: # luids.c errmsg.c echo x - luids.c cat >luids.c <<'Godfather_Of_Soul' #include "/us/ins/ubase.ins.c" #include "/us/ins/name.ins.c" #include "/us/ins/file.ins.c" #include <stdio.h> extern char *ErrMsg(); main(ac, av) int ac; char *av[]; { int i; for (i = 1; i < ac; i++) luids(av[i]); exit(0); } luids(name) char *name; { uid_$t uid; file_$attributes_t vh; obj_info_$t oi; status_$t st; name_$resolve(*name, (short) strlen(name), uid, st); if (st.all != status_$ok) { fprintf(stderr, "%s: can't resolve: %s\n", name, ErrMsg(st)); return; } printf("%s:\n", name); printf("Object: %08x.%08x\n", uid.high, uid.low); file_$get_attr_info(uid, file_$get_activ_mask, (short) sizeof vh, oi, vh, st); if (st.all != status_$ok) { fprintf(stderr, "%s: can't get attributes: %s\n", name, ErrMsg(st)); return; } printf("Type: %08x.%08x\n", vh.type_uid.high, vh.type_uid.low); printf("Parent: %08x.%08x\n", vh.dir_uid.high, vh.dir_uid.low); printf("User: %08x.%08x\n", vh.owner.high, vh.owner.low); printf("Group: %08x.%08x\n", vh.group.high, vh.group.low); printf("Org: %08x.%08x\n", vh.org.high, vh.org.low); } Godfather_Of_Soul echo x - errmsg.c cat >errmsg.c <<'Godfather_Of_Soul' #include <stdio.h> #include "/sys/ins/base.ins.c" char * ErrMsg(st) status_$t st; { static char msg[120]; short n; extern std_$call error_$get_string(); error_$get_string(st, msg, (short) (sizeof msg - 1), n); msg[n] = '\0'; return msg; } ErrPrint(s, st) char *s; status_$t st; { fprintf(stderr, "%s: %s\n", s, ErrMsg(st)); } Godfather_Of_Soul
rees@pisa.ifs.umich.edu (Jim Rees) (08/28/90)
In article <1990Aug28.110115@pisa.ifs.umich.edu>, rees@pisa.ifs.umich.edu (Jim Rees) writes:
[ lots of unintentionally wrapped text ]
Sorry about that last posting. I installed a new version of xrn (6.11) and
as usual it introduced more bugs (2) than it fixed (1). You'll have to fix
the program source code yourself, as I'm not going to bother re-posting it.
pcc@apollo.HP.COM (Peter Craine) (08/28/90)
In article <9008272051.AA01513@vlsi-mentor.jpl.nasa.gov>, root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) writes: |> |> What I need is a way to print the acl UID's of a file and plug that number |> into the ADOPT command so that person X's acls will be ok. |> At SR10.2 and later, the program /systest/ssr_util/acluid will display the ACL of a file and the UIDs corresponding to those ACL's. Consider the following example: % acluid . Acl for .: 3F041A5A.2000B623 00000000.00000000 00000000.00000000 pcc.%.% 00000000.00000000 00800040.00000000 00000000.00000000 %.none.% 00000000.00000000 00000000.00000000 14E54ABB.60000021 %.%.r_d 00000000.00000000 00000000.00000000 00000000.00000000 %.%.% 306F09C5.10004108 00000000.00000000 00000000.00000000 weber_w.%.% This says that the UID of person pcc = 3f041a5a.2000b623 and the UID of '%' = 0.0 So, if you've got a file owned by someone who was (accidentally or otherwise) deleted from the registry, you can find the UID and then ADOPT that UID into the person database. The documetation for ADOPT is straight-forward (at least is was to me). +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + "Home is where you wear your hat." Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP?
root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) (08/29/90)
Thank you! The "acluid" solved my problem and it worked like the proverbial charm. ---- Dave Hayes dave@vlsi-mentor.jpl.nasa.gov {ucbvax,ames}!elroy!vlsi-mentor!dave "The word 'choice' is a fraud when one is taught what to choose."
dbfunk@ICAEN.UIOWA.EDU (David B Funk) (08/29/90)
In article <9008272051.AA01513@vlsi-mentor.jpl.nasa.gov>, root@VLSI-MENTOR.JPL.NASA.GOV (The vlsi-mentor SysAdmin) writes: |> |> What I need is a way to print the acl UID's of a file and plug that number |> into the ADOPT command so that person X's acls will be ok. |> In response articles <1990Aug28.110115@pisa.ifs.umich.edu> Jim Rees & <4c78e8e5.20b6d@apollo.HP.COM> Peter Crane provide methods of determining the Domain/OS UIDs from the ACL of a file. This provides 90% of the battle but not quite all. At sr10 the registry data base has both the Domain/OS UID (Unique IDenifier, 64 bit number) of a name (person, group, or org name) its Unix ID number (UID, GID, OID, 16 bit number). Both of these numbers must be provided to the "adopt" command for edrgy. The Domain/OS UID is the most important value but if the Unix ID is not right, then there is a special step that need to be taken to work around it. The "fixvol" tool can be used to find both the Domain/OS UID and the Unix ID numbers from the ACL entry for a given file. The following sequence will illustrate this process: # here we have a file off a tape that has foreign ACLs $ acl ri.apollo.os.v.10.2 Acl for ri.apollo.os.v.10.2: Required entries ?(acl) invalid person identifier (US/aclm) ?(acl) invalid project identifier (US/aclm) %.%.none [ignored] %.%.% -r-x- Extended entry rights mask: ----- # the "acluid" tool can be used to display the Domain/OS UIDs $ /systest/ssr_util/acluid ri.apollo.os.v.10.2 Acl for ri.apollo.os.v.10.2: 3257DB31.20004108 00000000.00000000 00000000.00000000 unknown.%.% 00000000.00000000 24525C03.C0001967 00000000.00000000 %.unknown.% 00000000.00000000 00000000.00000000 00800080.00000000 %.%.none 00000000.00000000 00000000.00000000 00000000.00000000 %.%.% # Note the text "unknown" for both person & group names, but the # UID values are given as "3257DB31.20004108" & "24525C03.C0001967" # Before we can use "fixvol" we need the UID specifier of the file # itself. "/com/ld" can give us that with the undocumented "-u" flag. $ ld -u ri.apollo.os.v.10.2 uid name 481AC9C7.80020641 ri.apollo.os.v.10.2 1 entry listed. # Now we fire up "fixvol". # WARNING: # fixvol is a powerful tool that can easily trash your file system if not # used with care & respect. If you are at all uncertain about the next step, # skip it and go to the work-around at the end of this article. Do not give # any commands to fixvol that you are uncertain about. # This particular file was stored on logical volume #1 of disk "w" $ /systest/ssr_util/fixvol Warning: this program is intended only for the use of Apollo service representatives. Misuse of this program may irreparably damage your disk. To exit, type "q" to the following prompt. Fix-Volume utility, revision 10.2, 01/05/89 Select disk: [w=Winch|s=Storage mod|f=Floppy|q=Quit][ctrl#:][unit#][s] w (fv [p])> lv 1 # this sets the logical volume number to 1 (fv [1])> vu 481AC9C7 80020641 # this gives the command to read the header of our file UID hashes to bucket block at daddr = 2844B, bucket # 2(hex) ... UID contained within bucket block at daddr = 2844B, bucket # 2, index # 0 ... VTOCE contained within block at daddr = 2B0FB, index # 1 VTOCE # 1 ... at mem address 22958 ---Link to next partial block: 2AF82, vtoce count (v_cnt): 3 version = 1, sys_type = 0 (file_type) con_ctrl = 0 (none), permanent not-immutable not-audited object uid= 481AC9C7.80020641 /install/ri.apollo.os.v.10.2/ri.apollo.os.v.10.2 type uid= 321.00000000 unstruct_$uid dir uid= 481AC192.70020641 /install/ri.apollo.os.v.10.2 cur_len = 1FF47A, blocks_used = 2055(d), ref_cnt = 1, lock_key = 0 dtu= (4C67C284.936F) Saturday, August 25, 1990 1:48:34 am (CDT) dtm= (4670B56C.0000) Wednesday, October 25, 1989 10:26:16 am (CDT) dta= (481ACB7E.41F8) Thursday, January 18, 1990 3:48:01 am (CDT) dtv= (481ACB4A.641A) Thursday, January 18, 1990 3:47:47 am (CDT) Mgr_Data_a = 00000000 00000000 Mgr_Data_b = 00000000 00000000 Real Device # = 0000 owner uid (unix_id): 3257DB31.20004108 ( 3FB7) -PRWX- group uid (unix_id): 24525C03.C0001967 ( 39) -PRWX- org uid (unix_id): 00800080.00000000 ( C) -(ignore_rts)- World/Stat rights: -RX- -NO RIGHTS PRESENT- Extended acl uid: 00000000.00000000 0: 2B0FD 2B0FF 2B100 2B101 2B102 2B103 2B104 2B105 8: 2B106 2B107 2B108 2B109 2B10A 2B10B 2B10C 2B10D 16: 2B10E 2B10F 2B110 2B111 2B112 2B113 2B114 2B115 24: 2B116 2B117 2B118 2B119 2B11A 2B11B 2B11C 2B11D L1, L2, L3 filemaps: 46E20 46E21 0 (fv [1])> quit Now we have all the data we need to adopt the person & group names for the ACL of this file. The lines "owner" & "group" are what we need, note that the Unix IDs are given in hex. Domain/OS UID Unix ID owner uid (unix_id): 3257DB31.20004108 ( 3FB7) -PRWX- group uid (unix_id): 24525C03.C0001967 ( 39) -PRWX- However this may not be the end of the story. Although there will never be a collision problem with the Domain/OS UID (they don't call it Unique with out reason ;=) there is the possibility that the Unix ID number is alreay in use in your registry. Or there is the possibility that you cannot determine the Unix ID number. That's OK, you can punt it. With the Domain/OS UID firmly in hand, make up a new Unix ID to feed to "adopt". Once the real UID is stored in your registry, you can go back & fix up the Unix ID numbers in the file ACL with the "/etc/syncids" tool. Dave Funk