home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18014 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  6.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: Re: HELP: how to stop and prevent break in?
  5. Message-ID: <9211151420.AA26037@uu3.psi.com>
  6. Date: 15 Nov 92 13:17:11 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 116
  11.  
  12. I haven't been able to disentangle who asked and answered what in earlier
  13. parts of this thread, so I'll just try to respond to the underlying issues.
  14.  
  15. The first question appear to have been:  A file is shown, by DIRECTORY, to
  16. have ownership as follows:
  17.  
  18.     LOGIN.COM;3          [S892999,S882000]     (RWED,RWED,,)
  19.  
  20.  
  21. Both those long S numbers correspond to usernames on the system.  How did
  22. both of them get ownership of the file?
  23.  
  24. A correct answer was given:  This does NOT indicate multiple owners.  In fact,
  25. the VMS protection architecture does not allow multiple owners.  But this
  26. left the original questioner still puzzled about what was going on.
  27.  
  28. So, let's look at the basic principles.  Ownership and rights to objects are
  29. determined, in VMS, on the basis of identifiers.  Internally, identifiers are
  30. just 32-bit numbers.  However, people don't deal well with long numbers, so
  31. there are standard methods of representing identifiers.
  32.  
  33. First, however, you have to know that there are two kinds of identifiers,
  34. known as UIC-format identifiers and general identifiers.  Identifiers whose
  35. numerical values have the top bit set are general identifiers; the remaining
  36. identifiers are UIC-format.  A general identifier has no built-in semantics;
  37. it's simply a number assigned by the system manager or some VMS component.
  38. The default display format for a general identifier, absent other information,
  39. is as a hex string like %X80000001 - which, BTW, is the internal number that
  40. corresponds to the BATCH identifier that batch processes are granted by
  41. LOGINOUT.  Because the top bit of a general identifier is always 1, this
  42. representation is always 8 hex digits long, and the top hex digit is always
  43. in the range 8-F.
  44.  
  45. UIC identifiers are considered to have an internal structure:  The top 15 bits
  46. are called the group number, and the bottom 16 bits are called the member
  47. number.  Usernames have UIC's (that is, UIC-format identifiers) associated
  48. with them; when a process logs in with a username, it becomes identified with
  49. the UIC in its SYSUAF record.  The separation between group and member
  50. numbers is important because it determines when a process is to be granted
  51. rights to an object using the Group portion of the standard SOGW mask - the
  52. (RWED,RWED,,) in the example above - rather than only through the World
  53. portion.
  54.  
  55. The default representation for a UIC-format identifier, absent any other
  56. information, is [g,m], where g is the group number and m is the member
  57. number.  For historical reasons, g and m are written in OCTAL, not decimal
  58. or hex.  No leading %O is written with these numbers.
  59.  
  60. A UIC whose bottom 16 bits are all ones - in the standard representation,
  61. it would look like [g,177777] - is treated just a bit differently.  It is
  62. in some cases possible to use a wild card for a member number.  Internally,
  63. [g,*] is represented as [g,177777].  (A wild-card in the member number is
  64. also treated as all ones; but this rarely comes up, and I'm not sure if it's
  65. as 15 ones or as 16 ones.)  In contexts where wild-cards make no sense,
  66. [g,177777] is just another UIC-format identifier; but by convention it is
  67. not assigned to users, but is thought of as representative of the whole group.
  68.  
  69. Prior to V3 of VMS, there were no general identifiers; UIC's were all that
  70. existed, and they were represented only in the [g,m] form.  Actually, in
  71. those days they were 16 bits long, having been inherited in that form from
  72. RSX.  Along with the expansion to 32 bits and the addition of general
  73. identifiers, V3 brought a file called SYS$SYSTEM:RIGHTSLIST.DAT.  This file
  74. provides a way to associate textual names with identifiers.  These textual
  75. names are used in most instances in which you want to input an identifier;
  76. they are also used in most cases in which VMS prints and identifier.
  77.  
  78. For general identifiers, the rule for printing an identifier is simple:  If
  79. it has a translation in RIGHTSLIST, print just the name, an alphanumeric
  80. string.  Otherwise, print the old hex format.
  81.  
  82. For UIC-format identifiers, the process is a bit more elaborate.  Suppose the
  83. UIC is [g,m].  The rules are:
  84.  
  85.     - If [g,m] has translation MEMBER in RIGHTSLIST, AND [g,177777]
  86.         has translation GROUP in RIGHTSLIST, print [GROUP,MEMBER];
  87.     - Otherwise, if [g,m] has translation MEMBER, print [MEMBER].  Notice
  88.         that a general identifier would not have had the square
  89.         brackets around it.
  90.     - Otherwise print [g,m] in the old octal format.
  91.  
  92. Now, how do these various translations get into the RIGHTSLIST database?  You
  93. can add them yourself with appropriate system services or, more likely,
  94. AUTHORIZE's ADD/ID.  However, most RIGHTSLIST entries are created by AUTHORIZE
  95. using its default rules.  I've never seen them documented, but they appear
  96. to go as follows:
  97.  
  98.     Suppose we are adding user USER with UIC [g,m] and account ACCT.
  99.  
  100.     1.  If neither [g,m] nor USER has a translation in RIGHTSLIST, add
  101.         translations back and forth between USER and [g,m].
  102.     2.  If ACCT is not the null string and neither ACCT nor [g,177777] has
  103.         a translation in RIGHTSLIST, add translations back and forth
  104.         between ACCT and [g,177777].
  105.  
  106. Thus, by default, the UIC associated with USER can be represented on input as
  107. [USER], and will print as either [USER] or [ACCT,USER].  (If the latter
  108. version gets printed, it can also be used as input.)  There is no NECESSARY
  109. relationship between the username and the name used for the associated UIC -
  110. since multiple usernames can share a UIC, this is necessary.  But unless you
  111. do something unusual, AUTHORIZE's default actions will make them come out
  112. the same where possible - so most people are led to believe they are the
  113. same thing.  They aren't.
  114.  
  115. In the case of the original file:
  116.  
  117.     LOGIN.COM;3          [S892999,S882000]     (RWED,RWED,,)
  118.  
  119. we can now parse the owner as "group name" S892999, member S882000.  The
  120. fact that S892999 also happens to be a username is irrelevent - that's not
  121. the meaning of the string in this context.  Somehow, the procedure used to
  122. set up these usernames cause there to be a translation in the RIGHTSLIST
  123. from S892999 to [something,177777].  That's the only reason it's showing up in
  124. this format.  A look at the account setup procedure will probably show exactly
  125. why this happens.
  126.                             -- Jerry
  127.  
  128.