Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!ICAEN.UIOWA.EDU!dbfunk From: dbfunk@ICAEN.UIOWA.EDU (David B Funk) Newsgroups: comp.sys.apollo Subject: Re: Adopt and UID's Message-ID: <9008290805.AA07612@icaen.uiowa.edu> Date: 29 Aug 90 08:03:18 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Iowa Computer Aided Engineering Network, University of Iowa Lines: 130 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