From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Re: HELP: how to stop and prevent break in?
Date: 15 Nov 92 13:17:11 GMT
Distribution: world
Organization: The Internet

I haven't been able to disentangle who asked and answered what in earlier
parts of this thread, so I'll just try to respond to the underlying issues.

The first question appear to have been:  A file is shown, by DIRECTORY, to
have ownership as follows:

	LOGIN.COM;3          [S892999,S882000]     (RWED,RWED,,)


Both those long S numbers correspond to usernames on the system.  How did
both of them get ownership of the file?

A correct answer was given:  This does NOT indicate multiple owners.  In fact,
the VMS protection architecture does not allow multiple owners.  But this
left the original questioner still puzzled about what was going on.

So, let's look at the basic principles.  Ownership and rights to objects are
determined, in VMS, on the basis of identifiers.  Internally, identifiers are
just 32-bit numbers.  However, people don't deal well with long numbers, so
there are standard methods of representing identifiers.

First, however, you have to know that there are two kinds of identifiers,
known as UIC-format identifiers and general identifiers.  Identifiers whose
numerical values have the top bit set are general identifiers; the remaining
identifiers are UIC-format.  A general identifier has no built-in semantics;
it's simply a number assigned by the system manager or some VMS component.
The default display format for a general identifier, absent other information,
is as a hex string like %X80000001 - which, BTW, is the internal number that
corresponds to the BATCH identifier that batch processes are granted by
LOGINOUT.  Because the top bit of a general identifier is always 1, this
representation is always 8 hex digits long, and the top hex digit is always
in the range 8-F.

UIC identifiers are considered to have an internal structure:  The top 15 bits
are called the group number, and the bottom 16 bits are called the member
number.  Usernames have UIC's (that is, UIC-format identifiers) associated
with them; when a process logs in with a username, it becomes identified with
the UIC in its SYSUAF record.  The separation between group and member
numbers is important because it determines when a process is to be granted
rights to an object using the Group portion of the standard SOGW mask - the
(RWED,RWED,,) in the example above - rather than only through the World
portion.

The default representation for a UIC-format identifier, absent any other
information, is [g,m], where g is the group number and m is the member
number.  For historical reasons, g and m are written in OCTAL, not decimal
or hex.  No leading %O is written with these numbers.

A UIC whose bottom 16 bits are all ones - in the standard representation,
it would look like [g,177777] - is treated just a bit differently.  It is
in some cases possible to use a wild card for a member number.  Internally,
[g,*] is represented as [g,177777].  (A wild-card in the member number is
also treated as all ones; but this rarely comes up, and I'm not sure if it's
as 15 ones or as 16 ones.)  In contexts where wild-cards make no sense,
[g,177777] is just another UIC-format identifier; but by convention it is
not assigned to users, but is thought of as representative of the whole group.

Prior to V3 of VMS, there were no general identifiers; UIC's were all that
existed, and they were represented only in the [g,m] form.  Actually, in
those days they were 16 bits long, having been inherited in that form from
RSX.  Along with the expansion to 32 bits and the addition of general
identifiers, V3 brought a file called SYS$SYSTEM:RIGHTSLIST.DAT.  This file
provides a way to associate textual names with identifiers.  These textual
names are used in most instances in which you want to input an identifier;
they are also used in most cases in which VMS prints and identifier.

For general identifiers, the rule for printing an identifier is simple:  If
it has a translation in RIGHTSLIST, print just the name, an alphanumeric
string.  Otherwise, print the old hex format.

For UIC-format identifiers, the process is a bit more elaborate.  Suppose the
UIC is [g,m].  The rules are:

	- If [g,m] has translation MEMBER in RIGHTSLIST, AND [g,177777]
		has translation GROUP in RIGHTSLIST, print [GROUP,MEMBER];
	- Otherwise, if [g,m] has translation MEMBER, print [MEMBER].  Notice
		that a general identifier would not have had the square
		brackets around it.
	- Otherwise print [g,m] in the old octal format.

Now, how do these various translations get into the RIGHTSLIST database?  You
can add them yourself with appropriate system services or, more likely,
AUTHORIZE's ADD/ID.  However, most RIGHTSLIST entries are created by AUTHORIZE
using its default rules.  I've never seen them documented, but they appear
to go as follows:

	Suppose we are adding user USER with UIC [g,m] and account ACCT.

	1.  If neither [g,m] nor USER has a translation in RIGHTSLIST, add
		translations back and forth between USER and [g,m].
	2.  If ACCT is not the null string and neither ACCT nor [g,177777] has
		a translation in RIGHTSLIST, add translations back and forth
		between ACCT and [g,177777].

Thus, by default, the UIC associated with USER can be represented on input as
[USER], and will print as either [USER] or [ACCT,USER].  (If the latter
version gets printed, it can also be used as input.)  There is no NECESSARY
relationship between the username and the name used for the associated UIC -
since multiple usernames can share a UIC, this is necessary.  But unless you
do something unusual, AUTHORIZE's default actions will make them come out
the same where possible - so most people are led to believe they are the
same thing.  They aren't.

In the case of the original file:

	LOGIN.COM;3          [S892999,S882000]     (RWED,RWED,,)

we can now parse the owner as "group name" S892999, member S882000.  The
fact that S892999 also happens to be a username is irrelevent - that's not
the meaning of the string in this context.  Somehow, the procedure used to
set up these usernames cause there to be a translation in the RIGHTSLIST
from S892999 to [something,177777].  That's the only reason it's showing up in
this format.  A look at the account setup procedure will probably show exactly
why this happens.
							-- Jerry