Dec 092017
This file contains utilities that can help configuration management using DEC/VAX ACL entries to customize a users environment.
File VMS_ACL.ZIP from The Programmer’s Corner in
Category Alternate Operating Systems
This file contains utilities that can help configuration management using DEC/VAX ACL entries to customize a users environment.
File Name File Size Zip Size Zip Type
ACL_MENU.COM 6921 2052 deflated
BTN_SET.C 4612 1586 deflated
CFG_SET.C 3548 1313 deflated
DSC.H 1157 525 deflated
HELDBY.C 2318 866 deflated
TPCREAD.ME 199 165 deflated
VMS_ACL.DOC 6297 2479 deflated
WHOHAS.C 2327 885 deflated

Download File VMS_ACL.ZIP Here

Contents of the VMS_ACL.DOC file

Configuration Management Utilities

The programs included here demonstrate the control and utilization
that the DEC/VAX Access Control Lists (ACL) can provide. For those
unfamiliar with DEC/VAX ACL's, they are the extended security
protection mechanisms that provide capability to grant or deny any
resource to any individual or group of individuals. This can be an
extremely powerful way of creating a secure system.

In a normal unclassified setup, when creating a file, by default it
would have the normal protection scheme consisting of the normal
categories (unless the administrator set the system otherwise).
This file might appear as such:

$> directory/security

LOGIN.COM;84 5 4-JAN-1991 08:06:46.98 [MYGROUP,MYUSERID] (RWED,RWED,RE,)

In a secured system using ACL's an entry may appear as:

$> directory/security

GROUP.COM;84 5 4-JAN-1991 08:06:46.98 LIB_ALL_ID (RWED,RWED,RE,)

These ACL entries supersede any and all of the normal protection
attributes. In the case of the GROUP.COM file, it was created in
a directory that had the ACL feature enabled such that all files
placed in that directory assume the ownership of the identifier
LIB_ALL_ID not the person who placed it there. The creator still
has the READ, WRITE, EXECUTE, DELETE privileges but also the right
to CONTROL the ACL entries. The owner LIB_ALL_ID is an identifier
that the system administrator can place on any resource and
subsequently grant to any user or group of users. In this specific
example, anyone that holds the LIB_ALL_ID identifier can do as they
please with this file but the people that hold the identifier
LIB_RE_ID can only READ or EXECUTE this file.

If these identifiers are placed on an application directory and its
contents, the ACL becomes a mechanism for controlling access to
those systems. In this way an administrator can control exactly
who has use or control of a software system.
The down side of using ACL's is that time and effort must be spent
by the administrator to institute and maintain access permissions.
The authorize application and the sysuaf file are the only means of
determining the distribution of the identifiers. Unfortunately
these can only be used by the administrator. The database
administrators and software system developers may need to track and
request access for new users. In order for them to access this
privileged information it is necessary to call upon the VMS "System
Services" to acquire this information. The following example
applications can be run by any non-privileged user and therefor
should be protected (possibly by ACL) from usage by any non-trusted

heldby.c This is an application that will look up and
list all identifiers held by a given user.

whohas.c This is an application what will look up and
list the users that currently hold a given

The next set of utilities are designed to allow the
command file to automatically set up the users environment
dependant on the identifiers that the user holds at the time of
login. The purpose of these routines is to allow the system and
menus to configure themselves rather than trying to create and
manage many portions of logic and unique menus for each user or
group of users. (One sysop I know was pulling his hair out each
time a new user was added or personnel duties changed he had to
create yet another permutation of sylogin logic and user menus.
Now he just uses the authorize command to grant or revoke an
identifier) If the user holds an identifier for a software system
then the system can configure itself to include the logicals,
symbols, and execute any other code required for that software
system without other users even knowing that the system exists on
the machine. This will prevent users from listing the logical and
symbol tables and targeting the potential systems for infiltration.

button_set.c This routine will allow the to
query the users identifiers, and for each one
found it will create a VMS symbol for a menu
option to be displayed and one for executing
the application (see for an example).
This routine would most likely be used from a
captive account providing a user menu.

config_set.c This routine will allow the to
query the users identifiers, create a command
file containing any routines to execute. The can then call the command file to
set up any applications required for that user
and delete the command file when done.

The following depicts the usage of the automatic login
configuration program "config_set.c". When placed in the file it will automatically call all the DCL command
files for each project that the user has been granted the
identifier for. A file is written to the users
sys$scratch: and then executed. After the '.EXE' image has executed
the copies are purged to save space. The DCL procedure
would appear as:

$! This would be included as part of the procedure
$! ** Setting up all logicals and symbols for this user **
$! The parameters are read from SYS$INPUT as:
$! vax_identifier Command_to_execute
DATABASE1_RE @[setup]
APP2_DBA @[setup]
APP2_RE @[setup]
$! Execute the DCL setup file.
$ @sys$scratch:user_config
$! Purge or delete the command file.
$ purge sys$

 December 9, 2017  Add comments

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>