Article Title           : VMS-rights-database-funny
Creation Date           : unknown       
Author                  : ERW, NCD Technical Support
Last Update             : November 11, 1992
Last Update By          : ERW, NCD Technical Support
Expiration Rules        : Applies to NCDware until further notice.
Location		: NCD-Articles/Host_Systems/VMS
=============================================================================


      Object Ownership, the Rights Database, and the NDS_LOGIN Account
      ================================================================

Description
------------

Under certain rare circumstances, after the NCDware software installation is
complete, the system manager may note that files (and possible other named
objects such as queues and devices) which were previously owned by [SYSTEM]
are now owned by the identifier [SYSTEM,NDS_LOGIN].


Cause
------

This condition occurs only when the NCDware installation is applied against a
system with what might be termed an  "inconsistent" rights database (the data
contained in the file SYS$SYSTEM:RIGHTLIST.DAT).   Such inconsistencies can
result from the system's rights database being "built" or "rebuilt", at some
point, manually, from the UAF entries, rather than being created as the
result of the installation of a fresh copy of VMS. This can happen if the VMS
system under consideration has been in existence for a long time; i.e. before
the rights database and ACL-based protection was a part of VMS.  In these
cases, the actual value of the SYSTEM identifier is incorrect, it is wildcard
value [000001,177777], rather than [000001,000004].  If the value is
[000001,177777], then, instead of being a unique identifier, it becomes the
identifier associated with any UIC in group 1, and, any new identifier
assigned as a member of group 1 would then have the group ID of SYSTEM and a
member ID equal to the account name.

The result of this is that any object which appears to be owned by
[SYSTEM,NDS_LOGIN] is in fact owned by [1,4].  It is likely that in the past,
the ownership field was displayed as [1,4].  This was incorrect; the objects
should have been owned by [SYSTEM] but were not because the value of the
SYSTEM identifier was not [1,4] but rather [1,177777].  But when the
NDS_LOGIN account was added with a UIC of [1,4], this UIC received a unique
identifier which became [SYSTEM,NDS_LOGIN]. In general, this is not a
problem, but, if it is desired that the display of ownership be restored to
[1,4],  these instructions will remove the identifier associated with [1,4]
and return the files to being owned by an "unidentified" UIC of [1,4].  At
some point, it would be appropriate  to change the identifier of SYSTEM from
[1,177777] to [1,4], which is the VMS default for the SYSTEM account.


Repair Procedure
-----------------

Invoke into the Authorize utility:

$SET DEFAULT SYS$SYSTEM
$RUN AUTHORIZE
UAF> ! Remove the NDS_LOGIN identifier
UAF> REMOVE /IDENTIFIER NDS_LOGIN
UAF> ! OPTIONALLY repair value of SYSTEM Identifer
UAF> ! ONLY do this if you are CERTAIN of its effect on your system.
UAF> MODIFY /IDENTIFIER SYSTEM /VALUE=[1,4]
UAF> EXIT