VOS Registration and Security r283-04

VOS System Administration:
Registration and Security
Stratus Technologies
R283-04
Notice
The information contained in this document is subject to change without notice.

UNLESS EXPRESSLY SET FORTH IN A WRITTEN AGREEMENT SIGNED BY AN AUTHORIZED
REPRESENTATIVE OF STRATUS TECHNOLOGIES, STRATUS MAKES NO WARRANTY OR REPRESENTATION
OF ANY KIND WITH RESPECT TO THE INFORMATION CONTAINED HEREIN, INCLUDING WARRANTY OF
MERCHANTABILITY AND FITNESS FOR A PURPOSE. Stratus Technologies assumes no responsibility or obligation
of any kind for any errors contained herein or in connection with the furnishing, performance, or use of this document.
Software described in Stratus documents (a) is the property of Stratus Technologies International, S. r.l. or the third
party, (b) is furnished only under license, and (c) may be copied or used only as expressly permitted under the terms
of the license.
Stratus documentation describes all supported features of the user interfaces and the application programming
interfaces (API) developed by Stratus. Any undocumented features of these interfaces are intended solely for use by
Stratus personnel and are subject to change without warning.
This document is protected by copyright. All rights are reserved. No part of this document may be copied, reproduced,
or translated, either mechanically or electronically, without the prior written consent of Stratus Technologies.
Stratus, the Stratus logo, Continuum, Continuous Processing, StrataLINK, and StrataNET are registered trademarks
of Stratus Technologies International, S. r.l.
ftServer, ftServer with design, Stratus 24 x 7 with design, The Worlds Most Reliable Server, Selectable Availability,
XA/R, SQL/2000, and The Availability Company are trademarks of Stratus Technologies International, S. r.l.
RSN is a trademark of Lucent Technologies, Inc.
All other trademarks are the property of their respective owners.
Manual Name: VOS System Administration: Registration and Security
Part Number: R283
Revision Number: 04
VOS Release Number: 14.4.0
Printing Date: May 2001
Stratus Technologies, Inc.
111 Powdermill Road
Maynard, Massachusetts 01754-3409
2001 Stratus Technologies International, S. r.l. All rights reserved.
Contents
Preface
ix
1. Overview of Access Control and Security on VOS Modules

Access Control and Security Concepts
User Names
Person Names
Group Names
User Star Names
Access Codes and Access Lists
System Events and Auditing
How VOS Determines User Access
Preregistered User
1-1
1-1
1-2
1-2
1-2
1-3
1-3
1-3
1-4
1-5
2. Managing Group Directories

Groups and Group Directories
Planning the Group Directory Structure
Creating the Initial Group Directories
Adding a Group Directory
Storing Large Group Home Directories on Multiple Disks
Adding Disks for Expanded Group Directories
Expanding the Logical Volume Capacity
Moving a Group Directory to Another Disk
Deleting a Group
Groups in the Installation Software
2-1
2-1
2-1
2-2
2-3
2-4
2-5
2-6
2-6
2-7
2-8
Contents
iii
Contents
iv
3. Controlling Access to System Objects

Access Rights
Access Lists
File Access
File Access Rights
Displaying File Access Control Lists
Setting Access to Files
Directory Access
Directory Access Rights
Displaying Directory Access Control Lists
Setting Access to Directories
Default Access Control Lists (DACLs)
Propagating Access through a Set of Subdirectories
Device Access
Device Access Rights
Setting Access to Devices
Setting Access to STREAMS Drivers and Modules
Displaying Access to Devices
Internal Command Access
Internal Command Access Rights
Setting and Displaying Access to Internal Commands
Disabling Internal Command Access Rights
Access Control Set by Stratus
3-1
3-1
3-2
3-2
3-2
3-3
3-4
3-5
3-5
3-6
3-7
3-7
3-8
3-9
3-9
3-9
3-10
3-11
3-13
3-13
3-13
3-16
3-17
4. Registering Users
The Registration Databases
Adding a User to the System
Setting Up Home Directories
Deleting a User from the System
Changing a Current Users Data
Listing Registered Users
Managing User Passwords
Security
Restricting Passwords
Compatibility
Updating the Registration Database
4-1
4-1
4-3
4-4
4-7
4-8
4-9
4-9
4-9
4-9
4-11
4-12
VOS System Administration: Registration and Security (R283)
Contents
5. Managing Security
The Security Logging Facility
Security Log Message Format
login Command Error Messages
FTP Daemon Error Messages
System Auditing
Event Types
Auditing Users and Processes
Auditing Objects and Internal Commands
Event Entries in System Logs
Event Messages in the syserr_log.(date) File
Event Messages in the security_log.(date) File
Preventing Unauthorized FTP Access
Restricting User Passwords with set_password_security
Controlling Access with the login_admin Command
Limiting the Number of Users
Requiring a Special Password
Preventing Specified Users from Logging In
Removing Login Restrictions
Controlling Module Use with the logout_admin Command
Process Directory Management
RADIUS Support
Components
Commands
Configuration Files
Include Files
Queues
Subroutines
Configuration
RADIUS Server Queues
User Registration
Valid User Names
Valid Passwords
Registering Users for RADIUS Authentication
Registering Users for VOS Authentication
VOS RADIUS Authentication Server Messages
The basic Level Messages
The major Level Messages
The detail level Messages
Testing VOS RADIUS Support
RADIUS Server Communication Notes
Access-Request Packets
Access-Challenge
Restrictions
5-1
5-1
5-3
5-4
5-5
5-6
5-6
5-7
5-7
5-8
5-8
5-9
5-11
5-13
5-13
5-13
5-14
5-14
5-14
5-14
5-15
5-15
5-16
5-16
5-16
5-16
5-17
5-17
5-17
5-20
5-21
5-21
5-21
5-21
5-22
5-22
5-23
5-24
5-25
5-25
5-30
5-30
5-31
5-31
Contents
Contents
6. Command Overview
accounting_admin
audit_admin
configure_commands
create_user_sysdbs
display_registration_info
log_registered_users
login_admin
logout_admin
notify_security_violation
radius_admin
radius_auth_server
registration_admin
Adding a New User
Updating a Users Registration Information
Deleting a Users Registration Record
Processing Additions and Deletions as a Batch
security_admin
set_object_audit
set_password_security
set_priority
set_process_audit
set_registration_info
update_password_info
wait_for_overseer
wait_for_tp_overseer
7. Subroutines
s$get_registration_info
s$perform_ext_authentication
7-1
7-2
7-8
Appendix A. VOS Commands for Privileged Users
A-1
Index
vi
6-1
6-2
6-5
6-9
6-12
6-14
6-17
6-19
6-27
6-30
6-32
6-34
6-37
6-40
6-47
6-48
6-49
6-53
6-55
6-57
6-60
6-65
6-67
6-70
6-72
6-73
6-74
Index-1
Figures
Figure 4-1.
Registration Databases on a Three-Module System
4-3
Figures
vii
Tables
Table 3-1.
Table 3-2.
Table 3-3.
Table 3-4.
Table 5-1.
Table A-1.
viii
File Access Rights

Event Types
Privileged VOS Commands
3-3
3-5
3-9
3-13
5-7
A-1
Preface-
Preface
The VOS System Administration: Registration and Security (R283) documents access
and security management on VOS systems. This manual is intended for system
administrators and security officers.
Manual Version
This manual is a revision. Change bars, which appear in the margin, note the specific
changes to text since the previous publication of this manual. Note, however, that
change bars are not used in new chapters or appendixes.
This revision incorporates the following changes.
new information about preregistered users (Chapter 1)
system administrators are reminded about their special privileges (Chapter 2)
preventing unauthorized FTP access (Chapter 5)
support for the external RADIUS authentication service (Chapter 5)
new commands (Chapter 6)
radius_admin
radius_auth_server
changed commands (Chapter 6)
registration_admin
Chapter 7, Subroutines, which documents the following new subroutines:
Manual Organization
This manual contains seven chapters and one appendix.
Preface
ix
Preface
Chapter 1, Overview of Access Control and Security on VOS Modules, introduces the
access control and security system on VOS.
Chapter 2, Managing Group Directories, documents the creation and management of
group directories.
Chapter 3, Controlling Access to System Objects, details access rights, access lists,
and how to set access to files, directories, devices, and internal commands.
Chapter 4, Registering Users, documents the registration databases and the
procedures for adding and deleting users.
Chapter 5, Managing Security, explains system events and how to audit them.
Chapter 6, Command Overview, documents VOS registration and security
commands.
Chapter 7, Subroutines, documents VOS subroutines useful in writing programs for
RADIUS.
Appendix A, VOS Commands for Privileged Users, lists the VOS commands for
privileged users.
Related Manuals
Refer to the following Stratus manuals for related documentation.
VOS Commands Users Guide (R089)
VOS Commands Reference Manual (R098)
VOS System Administration: Administering and Customizing a System (R281)
Notation Conventions
This manual uses the following notation conventions.
Italics introduces or defines new terms. For example:
The master disk is the name of the member disk from which the module was
booted.
Boldface emphasizes words in text. For example:
Every module must have a copy of the module_start_up.cm file.
Preface
Monospace represents text that would appear on your terminals screen (such as
commands, subroutines, code fragments, and names of files and directories).

For example:
change_current_dir (master_disk)>system>doc
Monospace italic represents terms that are to be replaced by literal values. In the
following example, the user must replace the monospace-italic term with a literal
value.
list_users -module module_name
Monospace bold represents user input in examples and figures that contain both
user input and system output (which appears in monospace). For example:
display_access_list system_default
%dev#m1>system>acl>system_default
w
*.*
Preface
xi
Preface
Key Mappings for VOS Functions

VOS provides several command-line and display-form functions. Each function is
mapped to a particular key or combination of keys on the terminal keyboard. To
perform a function, you press the appropriate key(s) from the command-line or display
form. For an explanation of the command-line and display-form functions, see the
manual Introduction to VOS (R001).
The keys that perform specific VOS functions vary depending on the terminal. For
example, on a V103 ASCII terminal, you press the 6KLIW! and )! keys simultaneously
to perform the INTERRUPT function; on a V105 PC/+ 106 terminal, you press the ! key
on the numeric keypad to perform the INTERRUPT function.
NOTE
Certain applications may define these keys differently.
Refer to the documentation for the application for the
specific key mappings.
The following table lists several VOS functions and the keys to which they are mapped
on commonly used Stratus terminals and on an IBM PC or compatible PC that is
running the Stratus PC/Connect-2 software. (If your PC is running another type of
software to connect to a Stratus host computer, the key mappings may be different.)
For information about the key mappings for a terminal that is not listed in this table, refer
to the documentation for that terminal.
V103
ASCII
V103
EPC
IBM PC or
Compatible
PC
V105
PC/+ 106
V105
ANSI
CANCEL
)!
! or *
)!
CYCLE
)!
)!
$OW!-&!
!
)!
6KLIW!-)!
6KLIW!-)!
$OW!-%!
!
VOS Function
CYCLE BACK
DISPLAY FORM
)!
! or -
6KLIW!-)!
)! or
6KLIW!-+HOS!
HELP
6KLIW!-)!
6KLIW!-)!
6KLIW!-)!
6KLIW!-)!
+HOS!
INSERT DEFAULT
6KLIW!-)!
6KLIW!-)!
6KLIW!-)!
6KLIW!-)!
)!
)!
)!
)!
)!
,QVHUWB+HUH!
INTERRUPT
6KLIW!-)!
6KLIW!-'HOHWH!
$OW!-,!
!
6KLIW!-)!
NO PAUSE
6KLIW!-)!
6KLIW!-*
$OW!-3!
!
6KLIW!-)!
INSERT SAVED
Numeric-keypad key
xii
Preface
Format for Commands and Requests

Stratus manuals use the following format conventions for documenting commands and
requests. (A request is typically a command used within a subsystem, such as
analyze_system). Note that the command and request descriptions do not
necessarily include all of the following sections.
add_disk
Privileged
Purpose
The add_disk command tells the operating system on the current
module to recognize the specified logical volume for the duration of
the current bootload.
Display Form
-------------------------- add_disk ------------------------disk_name:
module_name: current_module
Command Line Form

add_disk disk_name
[ module_name ]
Arguments
Required
disk_name
The name of the logical volume to be recognized for the current
bootload.
.
.
.
A name
The name of the command or request is at the top of the first page of the
description.
B Privileged
This notation appears after the name of a command or request that can be issued
only from a privileged process. (See the online glossary, which is located in the file
>system>doc>glossary.doc, for the definition of privileged process.)
Preface
xiii
Preface
C Purpose
Explains briefly what the command or request does.

D Display Form
Shows the form that is displayed when you type the command or request name
followed by -form or when you press the key that performs the DISPLAY FORM
function. Each field in the form represents a command or request argument. If an
argument has a default value, that value is displayed in the form. (See the online
glossary for the definition of default value.)
The following table explains the notation used in display forms.
The Notation Used in Display Forms
Notation
Meaning
Required field with no default value.
The cursor, which indicates the current position on the
screen. For example, the cursor may be positioned on the
first character of a value, as in a ll.
current_user
current_module
current_system
current_disk
The default value is the current user, module, system, or

disk. The actual name is displayed in the display form of the
command or request.
E Command-Line Form
Shows the syntax of the command or request with its arguments. You can display
an online version of the command-line form of a command or request by typing the
command or request name followed by -usage.
The following table explains the notation used in command-line forms. In the table,
the term multiple values refers to explicitly stated separate values, such as two or
more object names. Specifying multiple values is not the same as specifying a star
name. (See the online glossary for the definition of star name.) When you specify
multiple values, you must separate each value with a space.
xiv
Preface
The Notation Used in Command-Line Forms

Notation
Meaning
argument_1
Required argument.
argument_1...
Required argument for which you can specify multiple values.
argument_1

argument_2
Set of arguments that are mutually exclusive; you must specify

one of these arguments.
argument_1
Optional argument.
argument_1 ...
Optional argument for which you can specify multiple values.
argument_1
argument_2
Set of optional arguments that are mutually exclusive; you can

specify only one of these arguments.
Note: Dots, brackets, and braces are not literal characters; you should not type them.
Any list or set of arguments can contain more than two elements. Brackets and braces
are sometimes nested.
F Arguments
Describes the command or request arguments. The following table explains the
notation used in argument descriptions.
G The Notation Used in Argument Descriptions
Notation
Meaning
&<&/(!
There are predefined values for this argument. In the display

form, you display these values in sequence by pressing the key
that performs the CYCLE function.
Required
You cannot issue the command or request without specifying a

value for this argument.
If an argument is required but has a default value, it is not labeled
Required since you do not need to specify it in the command-line
form. However, in the display form, a required field must have a
valueeither the displayed default value or a value that you
specify.
(Privileged)
Only a privileged process can specify a value for this argument.
Preface
xv
Preface
H The following additional headings may appear in the command or request
description: Explanation, Error Messages, Examples, and Related Information.

Explanation
Explains how to use the command or request and provides supplementary
information.
Error Messages
Lists common error messages with a short explanation.
Examples
Illustrates uses of the command or request.
Related Information
Refers you to related information (in this manual or other manuals), including
descriptions of commands, subroutines, and requests that you can use with or in
place of this command or request.
Online Documentation
Stratus provides the following types of online documentation.
The directory >system>doc provides supplemental online documentation,
including updates and corrections to Stratus manuals and a glossary of terms.

The VOS StrataDOC Web site is an online-documentation service provided by
Stratus. It enables Stratus customers to view, search, download, print, and

comment on VOS technical manuals via a common Web browser. It also provides
the latest updates and corrections available on the VOS document set.
If you are a Stratus customer with a current support contract, you can access the
VOS StrataDOC Web site, at no charge, at http://stratadoc.stratus.com.
You can also order the VOS StrataDOC CD-ROM from Stratus.
This manual is available on the VOS StrataDOC Web site.
For information about accessing the VOS StrataDOC Web site, contact the Stratus
Customer Assistance Center (CAC). For information about ordering the VOS
StrataDOC CD-ROM, see the next section, Ordering Manuals.
Ordering Manuals
You can order manuals in the following ways.
If your system is connected to the Remote Service Network (RSN), issue the
maint_request command at the system prompt. Complete the on-screen form

with all of the information necessary to process your manual order.
xvi
Preface
Customers in North America can call the Stratus Customer Assistance Center
(CAC) at (800) 221-6588 or (800) 828-8513, 24 hours a day, 7 days a week. All
other customers can contact their nearest Stratus sales office, CAC office, or
distributor; see the file cac_phones.doc in the directory >system>doc for CAC
phone numbers outside the U.S.
Manual orders will be forwarded to Order Administration.
Commenting on This Manual

You can comment on this manual by using the command comment_on_manual or by
completing the customer survey that appears at the end of this manual. To use the
comment_on_manual command, your system must be connected to the RSN. If your
system is not connected to the RSN, you must use the customer survey to comment
on this manual.
The comment_on_manual command is documented in the manual VOS System
Administration: Administering and Customizing a System (R281) and the VOS
Commands Reference Manual (R098). There are two ways you can use this command
to send your comments.
If your comments are brief, type comment_on_manual, press (QWHU! or 5HWXUQ!, and
complete the data-entry form that appears on your screen. When you have
completed the form, press (QWHU!.
If your comments are lengthy, save them in a file before you issue the command.
Type comment_on_manual followed by -form, then press (QWHU! or 5HWXUQ!. Enter

this manuals part number, R283, then enter the name of your comments file in the
-comments_path field. Press the key that performs the CYCLE function to change
the value of -use_form to no and then press (QWHU!.
NOTE
If comment_on_manual does not accept the part
number of this manual (which may occur if the manual is
not yet registered in the manual_info.table file), you
can use the mail request of the maint_request
command to send your comments.
Your comments (along with your name) are sent to Stratus over the RSN.
Stratus welcomes any corrections and suggestions for improving this manual.
Preface
xvii
Preface
xviii
Chapter 1
Overview of Access Control
and Security on VOS Modules
1-
This chapter introduces access and security administration on VOS modules. Sections
include:
Preregistered User

To regulate what users and groups can do on a module, Stratus has developed an
access control and security system. Access control and security determine:
who can log in
which system objects a registered individual can use
how many people can log in at a time
what system events are recorded
Access control is the mechanism by which the operating system determines users and
groups access rights to system objects, such as files, directories, devices, and internal
commands. Access rights are described in terms of access codes, single letter
designations representing these rights. These codes are documented in detail in
Chapter 3, Controlling Access to System Objects.
The access and security system for VOS modules has many features required by the
C2 security standard established by the United States government. VOS permits
discretionary access to system objects and the ability to audit system events. Each site
can determine the degree of use of the access and security features, beyond the
mandatory user registration feature and the default recording of events to the
syserr_log.(date) file.
Overview of Access Control and Security on VOS Modules
1-1
User Names
A user name is the identifier given an individual who is registered to use the system.
Typically, the user name corresponds to the person name of the individual, and to the
name of the users associated group. The general form of a complete user name is:
person_name.group_name
Some examples of user names are Jones.ne_sales1 and
Larry_Brown.marketing.
Note that valid characters for either the person name or the group name are numbers,
upper- and lowercase letters, underlines (_), and the special characters $, @, ~, [, ],
{, }, \, |, -, ^, , :, /, , and +. A period (.) separates the person name and the group
name. Asterisks (*) may be used to replace user name components, according to the
rules described in the section User Star Names later in this chapter.
Person Names
When a user is registered on VOS, the user is identified by a person name. The person
name must be a character string. The person name can closely resemble the users
actual name (such as Rosalyn_White or rwhite), or it can be a random character
string (such as c57d or thx1138). The users person name is defined by invoking the
registration_admin command. See Chapter 4, Registering Users, for more
information on this command.
Group Names
A group is a set of users. A group directory contains the user home directories of
the individuals in that group. A group directory helps allocate system resources and
access to system objects owned by that group. The name of a group directory is the
same as the name of the group. See Chapter 2, Managing Group Directories, for
more information on groups.
A user may be registered in more than one group. When only a person name is used
in a command (such as login Peter_Jones), the operating system assumes that
the value defined in the group1 field in the users registration file entry is the group
name. See Chapter 4, Registering Users, for more information on registration file
entries and how users are registered.
A user with the person name Peter_Jones is registered in the groups sales,
shipping, and inventory. The user names of Peter Jones, specifying each group
he belongs to, are:
Peter_Jones.sales
Peter_Jones.shipping
Peter_Jones.inventory
1-2
User Star Names

Most commands that accept user names can accept an asterisk (*) for one or both
parts of the user name. VOS interprets the user star name according to the following
rules.
An asterisk in place of the person name defines the set of all members of the group
specified in the group name. The user star name *.Treasury represents all
registered users in the Treasury group.
An asterisk in place of the group name defines the specified user in the set of all of
the groups in which he or she is registered. The user star name

Kelly_Callahan.* represents the user Kelly_Callahan in all the groups she
is registered in.
Asterisks for both components indicate the set of all registered users. The user star
name *.* represents all registered users.
Access Codes and Access Lists

A users access right to a system object determines what operations that user can
perform on that object. Access codes are stored in access control lists (ACL). Every
directory has an ACL. Every directory also has a default access control list (DACL),
which defines the default access for the files in that directory. System devices may
have device access lists associated with them, and internal commands may have
command access lists associated with them. By default, the access to all devices and
internal commands is determined by the access set on the system_default file in
the >system>acl directory. Access codes and access lists are documented in
System Events and Auditing

An event is any system occurrence initiated by a user. From a security standpoint, it is
useful to be able to audit any event that could represent a security problem. These
occurrences include any changes made to event auditing, object creation, destruction,
or modification and administrative actions. By selecting the system events to audit,
administrators can more effectively manage security for a system. See Chapter 5,
Managing Security, and the audit_admin, set_object_audit, and
set_process_audit commands in Chapter 6 for more information on events and
auditing.
1-3

When a user requests access to a file or directory, VOS searches the appropriate
access control lists to find the access of the user to that object. Here are the steps the
operating system follows to determine the access that the user
Gretchen_Smyth.Development has to the file bind.control.
1. VOS searches the ACL associated with the bind.control file for an entry
containing Gretchen_Smyth.Development. VOS gives her the access
associated with the entry Gretchen_Smyth.Development.
2. If VOS does not find an entry for Gretchen_Smyth.Development, but finds an
entry for Gretchen_Smyth.*, VOS gives her the access associated with that
entry.
3. If VOS does not find an entry for Gretchen_Smyth.Development, but finds an
entry for *.Development, VOS gives her the access associated with that entry.
4. If VOS does not find an entry for Gretchen_Smyth.Development,
Gretchen_Smyth.*, or *.Development, but finds an entry for *.*, VOS gives
her the access associated with that entry.
5. If VOS does not find an entry in the ACL for Gretchen_Smyth.Development,
Gretchen_Smyth.*, *.Development, or *.*, VOS then searches the default
access control list (DACL) associated with the containing directory. Steps 14
are repeated for the DACL for the files in that directory. If VOS finds an entry that
covers the user, the access right in that entry applies.
6. If there is no entry for the user on either the ACL or the DACL, the user has
undefined access to the file. This has the same effect as null access.
When the operating system is determining access for a directory, the operating system
follows Steps 14. A directory does not have its own DACLthe DACL associated with
a directory sets default access for all the files contained in that directory. If there is no
entry for the user in the directorys ACL, the user has undefined access to the
directory. See Default Access Control Lists (DACLs) in Chapter 3 for more
information.
For devices or internal commands, the operating system determines access by
searching the access list associated with the specified device, or the internal
command, if one exists. The operating system then follows Steps 14. If there is no
entry for the user in the access list, the user has undefined access to the device or
internal command. See Setting Access to Devices and Setting and Displaying
Access to Internal Commands in Chapter 3 for more information.
1-4
Preregistered User
Preregistered User
All Stratus systems are shipped with one preregistered user, Install, with a
password of secret. The first person who logs in with the Install user name must
change this password or disable the login for this user. To ensure system security, you
should not change the password back to secret at a later date.
CAUTION
If you disable the login for the Install user, you must
register at least one new user before logging out again or
you will not be able to log in at a later time.
1-5
Preregistered User
1-6
Chapter 2
Managing Group Directories
2-
This chapter documents how to manage group directories. Sections include:


Groups are sets of users. A user must be registered in at least one group and can be
associated with up to five groups. See Chapter 4, Registering Users, for information
about how to register a user in a group.
Every group corresponds to a group directory. Group directories are contained in the
top directory of a disks directory hierarchy. Most group directories are contained in the
(master_disk) directory. On modules with multiple disks, however, group
directories can be stored on other disks if there is a link in the (master_disk)
directory to each group directory.
The full path name of the group directory sales in the top disk directory #d01 on the
system %s1 is:
%s1#d01>sales
Planning the Group Directory Structure

Before registering users, plan the structure of group directories for your system. The
first stage in an orderly access-control arrangement is to plan the following:
how many groups to create
what name to assign to each group
how much disk space is needed and how much is available
how to best balance the disk load across the system
where to create the group directories
what access rights each group will need. (Chapter 3, Controlling Access to
System Objects, describes the access rights to system objects and how to assign
them.)
2-1
Creating the Initial Group Directories

After you plan the group directory structure, create the group directories. Follow these
general steps.
1. Change to the (master_disk) directory.
2. Link each group directory that is stored on a disk other than the master disk to the
master disk. The second example below illustrates this step.
3. Create a directory for each group, giving it the name of the group.
4. Define the access rights of each group by using the give_access and
give_default_access commands. This process is described in Chapter 3,
Controlling Access to System Objects.
If you do not define access, the operating system applies to each group the access
rights of the directory to which it is subordinate.
After creating the group directories and defining access to them, register users and set
up their home directories. See the instructions in Chapter 4, Registering Users.
The following brief example changes the current directory to the (master_disk)
directory, creates the group directory sales, and defines the access to the new group
directory.
change_current_dir (master_disk)
create_dir sales
give_access status sales -user *.sales
give_default_access read -user *.sales
The following brief example creates a link in the (master_disk) directory to a new
group directory, creates the group directory named inventory on the #d03 disk, and
defines the access to the new group directory.
change_current_dir (master_disk)
link #d03>inventory
create_dir #d03>inventory
give_access status #d03>inventory -user *.inventory
give_default_access read #d03>inventory -user *.inventory
See Chapter 3, Controlling Access to System Objects, for more information about the
access codes and access commands.
2-2
Adding a Group Directory

As the number of users on your system grows, you may need to add more group
directories. Before creating a new group directory, consider the following questions.
What is the estimated data storage requirement of each new group?
What access should other users and groups have to the contents of each new
directory?
NOTE
Keep in mind that the system administrator has full
privileges, and membership to the SysAdmin group
should be limited to users on an as needed bases
How many current users and new users will be assigned to each new group?
Should any current users assigned to a new group be removed from some other
group?
What is the best location for each new group directory? In general, the location of
the new group is related to the amount of free disk space on each disk. Monitor
current disk space used with the display_disk_usage and
display_disk_info commands. See VOS Commands Reference
Manual (R098) for information on these commands.
Here are the general steps to follow when creating additional groups.
2. If the new directory is to be stored on a disk other than the master disk, create a
link to the new directory in the (master_disk) directory.
3. Create the new group directory.
4. Define the access rights to the contents of the new group directory, using the
commands described in Chapter 3, Controlling Access to System Objects. (If you
do not define access, the operating system applies to the new group the access
rights of the directory to which it is subordinate.)
5. Issue the command registration_admin (described in Chapter 4,
Registering Users) to add or modify entries for users in the new group.
6. Examine the access rights of every current user reassigned to the new group, and
make changes if necessary. See the instructions for these procedures in
The following example shows the steps for adding the group inventory to the top
disk directory #d03, giving access to the inventory and sales groups to the
inventory directory, and creating a home directory for the user Jones in the group
directory.
2-3
1. change_current_dir (master_disk)
2. link #d03>inventory
3. change_current_dir #d03
4. create_dir inventory
5. give_access status inventory -user *.inventory
give_default_access read inventory -user *.inventory
give_access read inventory -user *.sales
give_access null inventory -user *.*
6. registration_admin
Register Jones as a new user.
7. change_current_dir #d03>inventory
NOTE
The registration_admin command should create the
home directory for Jones automatically. Check to see if
the home directory has been created. If it has been
created, skip Step 8 and proceed to Step 9. If it has not
been created, follow the instructions in Step 8.
8. create_dir Jones
9. give_access modify Jones -user Jones.*
give_default_access write Jones -user Jones.*
copy_file (master_disk)>system>abbreviations Jones
copy_file (master_disk)>system>start_up.cm Jones
10. display_access inventory -user Jones.inventory
See Adding a User to the System in Chapter 4 for detailed information about creating
home directories.
Storing Large Group Home Directories on Multiple Disks

Some groups are so large that home directories for users in the same group are not all
stored on the same disk. To set up a group directory that extends across multiple disks,
perform the following steps:
1. Calculate the number of home directories for each disk.
2. Create directories with the same group name on several different disks.
3. While registering users with the registration_admin command, be sure that
the differing disk names are entered in the user records.
4. Create links between the group directories, pointing to the home directories on the
other disks.
2-4
The following example shows some of the steps for adding the Engineering group with
its 40 users to disks #d01 and #d02.
1. Since there are 40 users in the Engineering group, plan to put 20 users home
directories on #d01 and the other 20 users home directories on #d02.
3. link #d01>Engineering
link #d02>Engineering
5. create_dir Engineering
6. give_access status Engineering -user *.Engineering
give_default_access read Engineering -user *.Engineering
give_access null Engineering -user *.*
8. create_dir Engineering
9. give_access status Engineering -user *.Engineering
give_default_access read Engineering -user *.Engineering
give_access null Engineering -user *.*
Add the users, adding 20 of them to #d01 and 20 of them to #d02. In this example,
the home directories for Joe Grenier and Nancy Pacek have been added to #d01
and the home directories for Linda McHugh and Paul Aronson have been added to
#d02.
11. Create links between the home directories on one disk and the group directory on
the other, to make it look like all the home directories in the Engineering group are
on the same disk:
change_current_dir #d02>Engineering
link #d01>Engineering>Joe_Grenier
link #d01>Engineering>Nancy_Pacek
change_current_dir #d01>Engineering
link #d02>Engineering>Linda_McHugh
link #d02>Engineering>Paul_Aronson
Adding Disks for Expanded Group Directories

On most systems, users need more disk space as system usage increases. Use the
commands display_disk_info and display_disk_usage to obtain information
about a disk, such as disk capacity and the number of disk blocks occupied. See VOS
System Administration: Disk and Tape Administration (R284) for more information
about disks.
2-5
Expanding the Logical Volume Capacity

You can install additional physical disks and then initialize them to be part of a logical
disk volume. To increase disk capacity, complete the following steps.
1. Physically install the new disks. See the maintenance manual associated with the
disk drive on your module and the VOS System Administration: Disk and Tape
Administration (R284) for more information on this procedure.
2. Initialize the primary partner of the new duplex disk with the initialize_disk
command. To make the disk part of a logical volume, supply the appropriate values
for the new_member and -n_members arguments. See VOS System
Administration: Disk and Tape Administration (R284) for more information.
3. Initialize the second partner with the command initialize_duplex_disk. Be
sure to specify the same member that was used in Step 2. See VOS System
With this method, the name of the top directory on the logical disk and the login
procedure remain the same.
Moving a Group Directory to Another Disk
If you do not want the new disks to be part of an existing logical volume, follow the steps
below. The following example shows how to move a group directory and create a link
in the (master_disk) directory to the group directory in its new location.
1. Physically install the new disks. See the maintenance manual associated with the
disk drive on your module and the VOS System Administration: Disk and Tape
Administration (R284) for more information on this procedure.
2. Initialize the primary partner of the new duplex disk with the initialize_disk
command. Use the default value for the new_member argument. See VOS System
3. Initialize the second partner with the command initialize_duplex_disk.
See VOS System Administration: Disk and Tape Administration (R284) for more
information.
5. Use the unlink command, if needed, to remove any existing links to the group
directory in its current location.
6. Use the move_dir command to move the group directory and all its contents to
the new disk.
7. Use the link command to link the master_disk directory to the group directory
in its new location.
Tell the users whose directories have been moved that the top directory name, and the
full path names of their directories are now different. There is no change in the login
procedure.
2-6
You do not have to update the registration database entries of users in a group that is
moved from the (master_disk) directory, if links exist in the (master_disk)
directory to the new location of the group.
See VOS System Administration: Disk and Tape Administration (R284) for more
information about initializing disks, and VOS Commands Reference Manual (R098) for
more information about the link, move_dir, and unlink commands.
Deleting a Group
Consider the following questions before deleting a group from your system.
Should users registered in this group be reassigned to another group or be
removed from the user registration database?

What should be done with this groups files and directories? Should they be
archived or should they be assigned to some other group?

If the groups files and directories are not to be saved or reassigned, inform other
system users about this situation and provide adequate time for them to copy whatever
information they require. When all files required by other users have been moved or
copied from this directory, perform the following steps.
1. Use the delete_dir command to delete the group directory.
2. If the deleted directory was on a disk other than the master disk, use the unlink
command to delete the link to the directory from (master_disk).
3. Use the command registration_admin to modify or delete the registration
records of users previously assigned to this group.
This example deletes the group old_records from the directory #d02.
1. delete_dir #d02>old_records
3. If the directory was stored on a disk other than #d02, issue the command
unlink #d02>old_records
Delete or modify entries for users assigned to the deleted group.
2-7

The installation software defines two groups:
SysAdmin
This group designates users who are defined as system administrators. They may
modify objects in the >system directory and may modify the registration files.
Members of the SysAdmin group can also register users, change passwords,
install software, and reboot the system.
NOTE
Keep in mind that the system administrator has full
privileges, and membership to the SysAdmin group
should be limited to users on an as-needed basis.
System
This group exists only to provide access control for system processes, such as
Overseer.System. Do not register any users in the System group.
The installation software gives these groups the highest level of access to system
objects. See Access Control Set by Stratus in Chapter 3 for more information.
2-8
Chapter 3
Controlling Access to
System Objects
3-
This chapter documents how to control access to files, directories, devices, and internal
commands, and describes the access granted by the installation software. Sections
include:
Access Rights
Access Lists
File Access
Directory Access
Device Access
The commands used to display and give access rights to system objects referenced in
this chapter are documented in VOS Commands Reference Manual (R098).
Access Rights
Access rights determine a users relationship to the object. The access right
determines if the user can modify the object, use the object, or even know that the
object exists. Access rights vary slightly from object to object and are described in the
following sections. An access code is an abbreviation for the name of an access right.
It is always the first letter of the name of the access right. For example, n signifies null
access.
Controlling Access to System Objects
3-1
Access Lists
Access Lists
There are four types of access lists:
access control lists
default access control lists
device access lists
internal command access lists
Access control lists (ACLs) and default access control lists (DACLs) are lists of entries
containing an access code and a user name, associated with a file or directory. The
entries determine who has access to the system object associated with the list, and
what type of access each user or group has. These lists are not stored in the directory
hierarchy as files, and can only be displayed or modified by using VOS access
commands, such as display_default_access or give_access.
An ACL is associated with a file or directory. A default access control list (DACL) is
associated with a directory, but its entries apply to the files within that directory.
Therefore, DACL entries contain only the file access rights (null, execute, read,
write). The purpose of DACLs is to simplify access control by allowing you to set
default access controls for all the files within a directory.
Each time you add an entry to an ACL or DACL, VOS evaluates the user values from
the most specific to the least specific. The operating system puts entries with person
names ahead of entries with asterisks as their first component. The procedure for
modifying these lists is described in Setting Access to Files and Setting Access to
Directories later in this chapter. The order in which entries are added to the list is not
significant.
Device access lists govern the access to devices. Internal command access lists
govern the access to internal commands. These lists are stored in the >system>acl
directory. These lists are created by VOS as empty files associated with devices or
internal commands. See Setting Access to Devices and Setting and Displaying
Access to Internal Commands later in this chapter for more information.
File Access
This section describes file access management.
File Access Rights

Access can be set on any type of file, whether it be a text file or an executable file. Four
types of access rights may be assigned to files, as defined in Table 3-1.
3-2
File Access
Table 3-1. File Access Rights

Access
Right
Access
Code
Description
undefined
Denies the user all access to the file. This code occurs only if
the effective access list for the file does not contain any entry
applicable to the given user name.
null
Denies the user all access to the file.
execute
Allows the user to execute a program module or command

macro, but not to read, modify, or delete it.
read
Allows the user to read the file (or to execute it, if it is

executable), but not to modify or delete it.
write
Gives the user full access to the contents of the file. (However,
to delete or write to the file, the user must have modify
access to the directory in which the file is contained.)
See Setting Access to Files later in this chapter for information on assigning file
access.
Displaying File Access Control Lists

To display the ACL for a file, invoke the display_access_list command, giving the
name of a file as the argument. See VOS Commands Reference Manual (R098) for a
full description of this command.
The following example displays the ACL for user Harry Eschers abbreviations file:
display_access_list
%acc#m1>Accounting>Harry_Escher>abbreviations
If the access for a file has never been modified or if access to the object is currently not
set, VOS displays only the full path name of the object:
The user has the access rights to the abbreviations file as designated by the DACL
of the containing directory. The file inherited the default access assigned to the files in
the directory. See Default Access Control Lists (DACLs) later in this chapter for
information on DACLs.
When access to a file has been set explicitly, the display_access_list command
lists any access right differences between the files ACL and the containing directorys
3-3
File Access
DACL. If Harry Escher gave write access to his abbreviations file to Dawn Chan,
invoking the display_access_list command displays the following:
w Dawn_Chan.Accounting
NOTE
Giving write access to a file is not enough to let Dawn
modify and save the existing abbreviations file. Dawn
also needs modify access to the containing directory.
See Setting Access to Directories later in this chapter for
more information.
To display your access to a file, invoke the display_access command, giving the
name of a file as an argument. If you invoke display_access abbreviations in
your home directory, VOS displays the following information:
display_access abbreviations
write (master_disk)>your_group>your_home_dir>abbreviations
Setting Access to Files

The following example gives Jay Jones, a member of the ca_sales group, write
access to the reports.93 file:
give_access write reports.93 -user Jay_Jones.ca_sales
NOTE
Before a user can modify a file and save the changes, the
user needs both write access to the file and modify
access to the containing directory. See Setting Access to
Directories in this chapter for more information.
Additionally, if the user is registered in multiple groups, the
group names must match before the user is given access
to the object.
The following example gives the az_sales group read access to the west file:
give_access read west -user *.az_sales
3-4
Directory Access
The following example removes Jo Berglands access from the abbreviations file:
remove_access abbreviations -user Jo_Bergland.*
NOTE
The user name specified by the remove_access
command must exactly match a user name in the ACL. If
the ACL listed Jo_Bergland.sales rather than
Jo_Bergland.*, the user named
Jo_Bergland.sales still has access to the file.
The following example removes the admin groups access from the tax.pm
command:
remove_access #d02>inventory_command_library>tax.pm -user
*.admin
The following example removes all users access from the sept.talk file:
remove_access sept.talk -all
Examples showing the use of the give_default_access and
remove_default_access commands appear in Default Access Control Lists
(DACLs), later in this chapter.
Directory Access
This section describes directory access management.

Access may be set on any directory on the disk, including the (master_disk)
directory. Three types of access rights may be assigned to directories, as defined in
Table 3-2.
Table 3-2. Directory Access Rights
Access
Right
Access
Code
(Page 1 of 2)
Description
undefined
Denies the user all access to the directory. This code occurs
only if the effective access list for the directory does not
contain any entry applicable to the given user name.
null
Denies the user all access to the directory.
3-5
Directory Access
Table 3-2. Directory Access Rights
(Page 2 of 2)
Access
Right
Access
Code
status
Allows the user to list the contents of the directory and to see
other status information, but not to change any of the contents.
modify
Gives the user full access to the contents of the directory.
Description
The undefined (u) code may be associated with a file or directory. This access code
cannot be specified with a give_access command. You may see it if you are a user
from an unknown group (group that is not defined to the current module) and you
attempt to display access for a directory where the user star name (*.*) has not been
defined. Undefined access gives the user access to files and directories equivalent to
null access.
See Setting Access to Directories later in this chapter for information on assigning
directory access.
Displaying Directory Access Control Lists

Directories always have associated ACLs. To display the ACL for a directory, invoke
the display_access_list command, giving the name of a directory as the
argument. See VOS Commands Reference Manual (R098) for a full description of this
command.
To display the ACL for Harry Eschers home directory, invoke the following command:
display_access_list %acc#m1>Accounting>Harry_Escher
VOS displays the following directory ACL:
%acc#m1>Accounting>Harry_Escher
m
m
m
s
s
s
n
Harry_Escher.*
*.SysAdmin
*.System
*.Accounting
*.Operator
*.Postmaster
*.*
This ACL indicates Harry Escher has modify access to his home directory, members
of the SysAdmin and System groups have modify access to the directory, members
of the Accounting, Operator, and Postmaster groups have status access to the
directory, and all other users (*.*) have null access to the directory.
3-6
Directory Access
The DACL for a directory contains access information for the files in that directory. See
Default Access Control Lists (DACLs) later in this chapter for information on DACLs.
Setting Access to Directories

The following example gives Mia Hagen modify access to the projects directory:
give_access modify projects -user Mia_Hagen.*
NOTE
Before a user can write out a file in a directory, the user
needs both write access to the file and modify access
to the containing directory. See Setting Access to Files
earlier in this chapter for more information.
The following example gives the az_sales group status access to Bill Smiths
planning directory:
give_access status #d01>admin>Bill_Smith>planning -user
*.az_sales
The following example removes Meg Singers access from the reports directory:
remove_access reports -user Meg_Singer.admin
The following example removes the admin groups access from the taxes directory:
remove_access taxes -user *.admin
The following example removes all users access from the mail directory:
remove_access #d04>az_sales>Morgan>mail -all
Default Access Control Lists (DACLs)
To display the DACL for a directorys files, invoke the
display_default_access_list command, giving the directory name. See VOS
Commands Reference Manual (R098) for a full description of this command.
To display the DACL for the files in Harry Eschers home directory, invoke the following:
display_default_access_list %acc#m1>Accounting>Harry_Escher
3-7
Directory Access
VOS displays the DACL for the files in the directory.

%acc#m1>Accounting>Harry_Escher
w
w
w
r
r
n
Harry_Escher.*
*.SysAdmin
*.System
*.Accounting
*.Operator
*.*
Remember, the access rights listed in a directorys DACL are file access rights, not
directory access rights. This DACL indicates Harry Escher has write access by
default to the files in his home directory, members of the SysAdmin and System
groups have write access by default to the files, members of the Accounting and
Operator groups have read access by default to the files, and all other users (*.*)
have null access by default to the files.
The following example gives Jim Anthony default write access to the files in Sue
Franciss sales directory:
give_default_access write Sue_Francis>sales -user
Jim_Anthony.admin
The following example gives the mis group default read access to the files in Cory
Nicias tools directory:
give_default_access read #d01>admin>Cory_Nicia>tools -user
*.mis
The following example removes the admin groups default access from the files in the
records directory:
remove_default_access records -user *.admin
Propagating Access through a Set of Subdirectories
You can copy the access from a directory throughout its subdirectories by using the
propagate_access command. The following example copies the 92_record
directorys access rights to all its subdirectories:
propagate_access 92_record
See VOS Commands Reference Manual (R098) for a full description of this command.
3-8
Device Access
Device Access
This section describes device access management, including access management for
STREAMS drivers and modules. Each site has the option to restrict access to specified
devices. Administrators not implementing device access control can disregard this
section.

Access may be set to any device, including STREAMS drivers or modules, configured
on the current module. Three types of access rights may be assigned to devices, as
defined in Table 3-3.
Table 3-3. Device Access Rights
Access
Right
Access
Code
Description
null
Denies the user all access to the device.
read
Allows the user to use a device for reading or input and any
corresponding s$control operations.
write
Allows the user to use a device for reading or input, writing or

output, and any corresponding s$control operations.
When a tape drive is associated with a device access list, a user needs read or write
access to the tape drive in order to use it. All other devices require write access.
See Setting Access to Devices for information on setting device access. See Setting
Access to STREAMS Drivers and Modules for information on setting access to
STREAMS drivers and modules.
Setting Access to Devices

Restrict access to devices by specifying an access list for each device. Device access
lists are created by the configure_devices command and are stored in the
>system>acl directory on each module. The access set on a device access list
determines the access for the device(s) associated with the device access list. Devices
and internal commands on the same module can share the same device access lists.
In order to associate a device access list with a device, the access_list_name field
needs to be added to the appropriate device record in the devices.tin file, located
in >system>configuration.
3-9
Device Access
The following procedure illustrates how to restrict access to a specific device. In this
example, the devices.tin file is edited to associate the tape.1.0 tape drive with
the tape1_dev device access list. To set access to tape.1.0, perform these steps.
1. Edit >system>configuration>devices.tin to add the
access_list_name field to the device definition. Give the device access list a
meaningful name. Here are the relevant excerpts from the devices.tin file.
=name
=module_name
=device_type
=slot
=channel
=access_list_name
tape.1.0
m1
tape
29
0
tape1_dev
See VOS System Administration: Configuring a System (R287) for more

information on updating the devices.tin file.
2. Invoke create_table and broadcast_file to create a new devices.table
file and to broadcast it throughout the system.
3. Invoke the configure_devices command. VOS recognizes the newly
broadcast devices.table file and creates the >system>acl>tape1_dev
device access list.
4. To set access to tape.1.0, execute the give_access command:
give_access write (master_disk)>system>acl>tape1_dev
-user *.SysAdmin
give_access read (master_disk)>system>acl>tape1_dev
-user *.Support
A user in the SysAdmin group can read data from or write data to tape.1.0, but
a user in the Support group can only read data from the tape drive.
To change the access of a device that already has a device access list, invoke Step 4
of the procedure above.
Setting Access to STREAMS Drivers and Modules

You restrict access to STREAMS drivers and modules by specifying an access list for
each driver or module. Device access lists are created by the configure_devices
command and are stored in the >system>acl directory on each module. The access
set on a device access list determines the access for the drivers and modules
associated with the device access list. Drivers, modules, and internal commands on the
same module can share the same device access lists. In order to associate a device
access list with a driver or module, the access_list_name field needs to be added
3-10
Device Access
to the appropriate device record in the devices.tin file, located in the directory
>system>configuration.
The following procedure illustrates how to restrict access to a specific STREAMS driver
or module. In this example, the devices.tin file is edited to associate the
echo_read driver with the streams_read_access device access list. To set access
to echo_read, perform the following steps.
1. Edit >system>configuration>devices.tin to add the
access_list_name field to the device definition. Give the device access list a
meaningful name. Relevant excerpts from the devices.tin file follow.
=name
=module_name
=device_type
=access_list_name
=streams_driver
=clone_limit
echo_read
m5
streams
streams_read_access
echo
10
See the manual VOS System Administration: Configuring a System (R287) for
more information about updating the devices.tin file.
2. Invoke create_table and broadcast_file to create a new devices.table
file and to broadcast it throughout the system.
3. Invoke the configure_devices command. VOS recognizes the newly
broadcast devices.table file and creates the
>system>acl>streams_read_access device access list.
4. To set access to echo_read, issue the give_access command.
give_access read >system>acl>streams_read_access -user *.*
All users can read data from echo_read.
To change the access of a driver or module that already has a device access list,
perform Step 4 of the preceding procedure.
Displaying Access to Devices
To determine if device access has been set for any devices (including STREAMS
drivers and modules) on the current module, change to the >system>acl directory.
3-11
Device Access
The acl directory, by default, contains a file named system_default. Access on the
system_default file is set by default as follows:
display_access_list system_default
%se#m24>system>acl>system_default
w
*.*
display_default_access_list
%se#m24>system>acl
r
*.*
If you find other files in the acl directory, it means that some devices, drivers, modules,
or internal commands have associated access lists. To determine which devices are
associated with the access lists, edit the >system>configuration>devices.tin
file and search for the name of the access list. The access list name appears in each
record of its associated device(s). Once you find the name of the device access list for
a command, use the display_access_list command to display the access set on
the device access list.
display_access_list
(master_disk)>system>acl>device_access_list
If the device access list does not have an ACL, issue the
display_default_access_list command to display the DACL for the files in the
acl directory.
To determine if a specific device has a device access list, use the dump_dvt request
of the analyze_system command, specifying the name of the device that you want
more information about. The Access Control List information appears at the end of the
lengthy output of this request.
Access Control List at 006D3680
hash_link:
00000001
acl_file_name: system_default
ref_count:
215
See the VOS System Analysis Manual (R073) for more information about the
analyze_system command.
To give access to or remove access from a device with an existing device access list,
invoke a give_access or remove_access command on the appropriate device
3-12
access list. See Setting Access to Files earlier in this chapter for information about
file access.

This section describes internal command access management. Each site has the
option to set access to specified internal commands. Administrators who are not
implementing internal command access control can disregard this section.

An internal command is a command that is part of the VOS kernel. These commands
are not stored in command libraries. To determine whether a command is an internal
command, issue the following command:
help -type internal
VOS displays a list of all internal commands. The only way to set access to internal
commands is by following the procedure documented in Setting and Displaying
Access to Internal Commands later in this chapter. Four types of access rights can be
assigned to internal commands, as defined in Table 3-4.
Table 3-4. Internal Command Access Rights
Access
Right
Access
Code
Description
execute
Allows the user to execute the internal command.
null
Denies the user all access to the internal command.
read
write
Setting and Displaying Access to Internal Commands

Access to internal commands, commands that reside in the VOS kernel rather than in
a command library, can be restricted by specifying an access list for each command.
Internal command access lists reside in the system-created >system>acl directory
and are created by VOS. Internal command access lists are updated by the
configure_commands command. The access set on an internal command access
list determines the access for the command(s) associated with the internal command
access list. The internal_commands.tin file associate internal commands and
access lists. Devices and internal commands on the same module can share the same
internal command access lists.
3-13
The internal_commands.dd file defines the format for each command entry in the
internal_commands.tin file as follows:
/* To ensure correct system operation, this */
/* file must never be modified by customers. */
/* This is the internal command access control file data
definitions. */
fields:
version
name
access_list_name
audit
mbz_flags
fixed bin (15) default (2),

char (32) varying, /* Required */
char (32) varying,
bit (1),
bit (15);
end;
To associate an internal command with an access list, create the
internal_commands.tin file. Enter the name of an internal command, and the
name of an access list, as shown in the following example:
/=name
=access_list_name
update_channel_info
uci_com
NOTE
If a value is not supplied for access_list_name, VOS
gives the access list the same name as the command.
In general, these are the only two fields that need to be added to the
internal_commands.tin file. However, you may also indicate which internal
commands should be audited. The following information enables object auditing on the
copy_file command:
/=name
=access_list_name
=audit
copy_file
system_default
1
See the documentation for the configure_commands and set_object_audit

commands in Chapter 6, Command Overview, for information on auditing internal
commands.
To see if an internal command has an associated internal command access list, edit
the internal_commands.tin file, and search for the name of the internal command.
If the command is not in the file, then it does not have an internal command access list.
3-14
Access for VOS commands that are not internal commands can be changed by setting
the access on the command libraries in which they reside. You can set access per
command in a command library by setting access to the commands .pm file. See
Setting Access to Files earlier in this chapter for information on setting access to
individual files. Internal commands may share access lists. Internal commands may
also share access lists with a device that is located on the same module.
If you plan to use internal command access, follow these steps:
1. Create the internal_commands.tin file, using the format defined in the
internal_commands.dd file. Add the names of the commands to restrict access
to, the names of their associated access lists, and if the command is to be
auditable, the line =audit 1. See the documentation for the
configure_commands command in Chapter 6, Command Overview, for more
information.
2. Invoke the create_table command on the internal_commands.tin file.
3. Be sure a copy of internal_commands.table is copied to the
(master_disk)>system directory.
4. Invoke the configure_commands command.
5. Change your current directory to (master_disk)>system>acl. To set the list
of users and access rights, execute the give_access command for each internal
command access list specified in the internal_commands.tin file. Access on
internal commands is maintained after subsequent boot loads if the
configure_commands command is added to the module_start_up.cm file.
CAUTION
It is possible to disable all access to all internal commands
when setting access to these access lists. If null access is
given to all users (*.*) for all internal command access
lists, none of the internal commands may be executable.
Do not give null access to all users. See Disabling
Internal Command Access Rights in this chapter if you
accidentally set null access to all internal commands or
call the CAC.
To change the access of a command already listed in the internal_commands.tin
file, invoke Step 5 of the procedure above.
To display the ACL for an internal command, first determine the name of its access list.
Check the internal_commands.tin file for this information. If the list command
3-15
is associated with the internal command access list named list_com, enter the
following command to display the ACL that governs access for the list command:
display_access_list (system)>system>acl>list_com
If the internal command access list does not have an ACL, invoke
display_default_access_list to display the DACL for the files in the acl
directory.
To give access to or remove access from an internal command with an existing internal
command access list, change to (master_disk)>system>acl and invoke the
give_access and give_default_access commands on the appropriate files. See
Setting Access to Files earlier in this chapter for information file access.
Access for commands stored in command libraries is controlled by file and directory
ACLs. See Setting Access to Files and Setting Access to Directories, earlier in this
chapter, for more information.
Disabling Internal Command Access Rights
It is possible to remove access from all internal commands for all users by accidentally
setting the access to null for all users. Since a module is unusable when all internal
command access is removed, the module must be rebooted manually. System
administrators may reset the access rights of all internal commands for all users during
a manual reboot. The following question has been added to the manual reboot queries:
Override all internal commands access to system default?
A yes answer resets all existing internal commands access to write for all users.
3-16

The initial access configuration sets the following access rights.
To all top directories in disk directory hierarchies, users who are logged in as
privileged and are in the SysAdmin group, have modify access. All other users
have null access. This is the only instance of a relationship between access and
privilege.
The Privileged field in each users registration database entry determines
whether that user can log in as privileged.

To the >system directory, users logged into the groups SysAdmin and System
have modify access, and all other users have status access. The ACL for >system
is:
m
m
s
*.SysAdmin
*.System
*.*
To the files in the >system directory (except the files containing user passwords),
users logged into the groups SysAdmin or System have write default access,
while all other users have read default access. The DACL for >system is:
w
w
r
*.SysAdmin
*.System
*.*
To the file user_registration.sysdb, users logged into the group SysAdmin
have write access and all other users have read access. The ACL for
user_registration.sysdb file is:
w
r
*.SysAdmin
*.*
To the file change_password.sysdb, users logged into the groups SysAdmin or
System have write default access, while all other users have null access. The ACL
for change_password.sysdb is:
w
w
n
*.SysAdmin
*.System
*.*
To all devices and internal commands, all
users have write access.
3-17
3-18
Chapter 4
Registering Users
4-
This chapter describes the registration databases, which contain all the information
about the users (local and remote) who can log in to the system. Sections include:

The systems registration database files, user_registration.sysdb and
change_password.sysdb hold registration information for all users of a VOS
system. These databases and their links are created by the command
create_user_sysdbs. Issue this command only when a new system is being
installed or if a module is being added to an existing system. The
create_user_sysdbs command must be given once for each module on the
system. For a detailed description of the create_user_sysdbs command, see
Chapter 6, Command Overview.
The master versions of the registration database files are kept on the master module
of a system; all other modules in the system have copies of the databases plus a link
to the master version of the password database file. The operating system does not
support separate password database files on each module in a system.
To log in to the system, invoke the login command at the Please login prompt.
Enter your user name and password. For more information about the login command,
see VOS Commands Reference Manual (R098).
To verify that the user is a registered user, the operating system searches the
user_registration.sysdb for an entry that matches the user name given in the
login command. For users registered with a VOS password, the operating system
also searches in the password database file, named change_password.sysdb, for
an entry that matches the password the user entered. For users registered to required
Registering Users
4-1
external authentication, VOS communicates with an external authentication service.

See RADIUS Support in Chapter 5 for more information about external
authentication services.
If the user is authenticated, and the user has write access to the login device, the
operating system logs in the user. If the user is not authenticated, the operating system
displays the message Access denied and displays the Please login message
again. If the user has non-write access to the login device, the message Not enough
access to perform operation is displayed.
If your system is part of a local network or a wide area network, the registration
databases can contain entries for users from other systems. To log in to your system,
a remote user must have an entry in your registration database file. However, a remote
user may or may not be required to have an entry in order to access files on your
system. The conditions for both remote login and remote access for local networks are
described in VOS StrataLINK Administrators Guide (R192); for wide area networks,
they are described in VOS Communications Software: X.25 and StrataNET
Administration (R091).
Figure 4-1 illustrates the relationship among the files, directories, and links in the
directory >system on each module in a three-module system. The
forbidden_passwords.table file is an optional file. See Managing User
Passwords later in this chapter for information on this file. Note that the file
change_password.sysdb in the directory >system>configuration on the
master module is the ultimate target of the link master_password.sysdb in the
directory >system on each module. Do not unlink this link.
4-2
Master Module m1
(master_disk)>system
Files:
change_password.sysdb
user_registration.sysdb
forbidden_passwords.table
Link:
master_password.sysdb
link to
(master_disk)>system>configuration
Files:
Module m2
Files:
Link:
link to
Module m3
Files:
Link:
link to
Figure 4-1. Registration Databases on a Three-Module System

To add a new user to the system, use the registration_admin command, which
adds information to the registration databases. This command can also create one or
more home directories for that user. The registration_admin command displays
a main menu, showing the actions from which to choose. These screens are fully
documented in the description of the registration_admin command in Chapter 6,
Command Overview. To add information to the registration databases, use either the
Registering Users
4-3
add_user action or the process_table action. The process_table action

processes a table file, which adds many user records in a batch process.
If a user is registered with the must_have_start_up_program attribute of the
registration_admin command, and VOS cannot invoke the users start_up.cm
file during an initial login, VOS will log out the user. For example, if you attempt to log
in but your start_up.cm file is not an executable file, VOS returns the following
message and then logs you out.
command_processor: The program module is not a VOS executable
program module.
NOTE
This condition does not apply to batch logins, subsequent
logins from a VOS command prompt, or start_process
commands.
Setting Up Home Directories

Each registered user must have at least one home directory, in which some or all of the
users subdirectories are located.
NOTE
The root directory of the master disk should not be used
as a home directory.
You can register users in several groups for accounting purposes or as a means of
controlling access. The files belonging to a user registered in multiple groups are
usually stored in one home directory, the principal home directory, and its
subdirectories. The group directory for each of the other groups in which the user is
registered usually contains a link to the principal home directory. Remember that if you
create new groups, you must create a new group directory for each group created. See
Adding a Group Directory in Chapter 2 for more information.
The group directory that contains the principal home directory should be the directory
named in the first Groups field in the ADD NEW USER screen for that user. This screen
also has a Home Dir: field. Specify a home directory in one of several ways:
Give a full path name or a path name that contains (master_disk).
registration_admin then inserts the path name into the user registration
tables exactly as given.
4-4

Give a partial path name of the form >group_name>person_name.
registration_admin then concatenates the (master_disk) command

function with the partial path name and inserts this modified version.
Give a full path name having the default home directory path name format,
(master_disk)>group_name>person_name, where group_name is the first

group specified in the ADD NEW USER form. The registration_admin
command then creates the home directory automatically.
Give the null string. registration_admin first tries to obtain a value from the
Default Module field, prompting for a value if necessary. If successful, it

concatenates the name of the master disk on the specified module with the values
in the first Groups field and the Name field, separating them with greater-than
symbols (>), and creates the default home directory with the name that results. If
unsuccessful, it returns the following message after you press (17(5! from the
second form:
Warning: Unable to create home_dir
NOTE
Use the process_table action to create the default
home directory automatically by including the
create_home_dir field in the .tin file. The command
follows the same procedure described above. See
detailed information on process_table and the
registration_admin.tin file in Deleting a User
from the System later in this chapter.
When the registration_admin command creates the default home directory, it
also performs the following activities:
gives modify access to the home directory and write default access the files it
contains to the person being registered

copies the standard abbreviations and start_up.cm files from the >system
directory into the home directory

creates links from directories of other groups specified in the Groups field to the
home directory
creates links from other modules having directories with the same names as the
groups specified in the Groups field.
Registering Users
4-5
If you do not instruct the registration_admin command to create a home directory,

or if the command is unable to create the directory, or if you are registering the user to
use Office/2000, create the home directory manually. Perform the following tasks:
1. create the home directory, typically in the form >group_name>person_name
2. copy the start_up.cm and abbreviations files into that home directory
3. create any links that are required
4. give the new user modify access to the directory and write default access to the
files in the directory.
The remainder of this section describes how to create a home directory for a user
registered in more than one group. The registration_admin command assumes
that you are creating a principal home directory and linking the users other home
directories to it. To create home directories in more than one group directory, repeat
Steps 1 through 4 for each additional group directory.
1. Change to the group directory listed in the first line of the Groups field of the users
entry in the registration database.
2. Create the home directory with the create_dir command, giving the users
person name as the directory name.
3. Use the give_access and give_default_access commands, referenced in
Chapter 3, Controlling Access to System Objects, to assign the users access.
Assign modify access to the directory and write default access to the files in the
directory.
4. Use the copy_file command to copy two files from the directory
(master_disk)>system into the new home directory. These files are:
abbreviations, which contains a set of standard operating system
abbreviations for all commands.

start_up.cm, which contains standard user startup commands.
These files are described in VOS System Administration: Administering and

Customizing a System (R281).
NOTE
An alternative to copying the abbreviations and
start_up.cm files into each users home directory is to
create links in each home directory to a single master
copy of each of the files. This method lets the system
administrator maintain these files, and reduces the
number of duplicate files. However, this method makes it
impossible for individual users to tailor these files to their
own needs and preferences. For information about
4-6
creating links, see the description of the link command

in VOS Commands Reference Manual (R098).
5. If the user is registered in more than one group, change from the current directory
to one of the other group directories.
6. Create a link to the principal home directory.
7. Repeat Steps 5 and 6 for each additional group in which the user is registered. (A
user can be registered in no more than five groups.) Only repeat Steps 1 through
4 if you are creating multiple home directories for the user.
This example presumes that the group given on the first line of the group field is
Marketing, and that a second group Inventory is also given in the group field. The
example shows a command sequence that creates a principal home directory for
Jones, gives Jones the necessary access, copies the two standard files to the
directory, and creates a link to the principal home directory in a second group directory.
1. change_current_dir (master_disk)>Marketing
2. create_dir Jones
3. give_access modify Jones -user Jones.*
give_default_access write Jones -user Jones.*
4. copy_file >system>abbreviations Jones
copy_file >system>start_up.cm Jones
5. change_current_dir (master_disk)>Inventory
6. link (master_disk)>Marketing>Jones

The delete_user action provides a form to delete existing user records, one record
at a time. The registration_admin command prompts for the person_name of the
user whose information is to be deleted from the registration databases. The command
then asks for verification that this users record is to be deleted. If you specify yes, the
users records in user_registration.sysdb and change_password.sysdb are
deleted and the modified databases are broadcast to all other modules in the system.
Since the delete_user action deletes user records one at a time, use it only when
processing a small number of records. The process_table action, however, allows
you to delete a large number of user records in a batch process.
Before using the process_table action, create a table input file named
registration_admin.tin. This file contains the user records to be modified or
deleted. After modifying this file, use the create_table command to convert the
.tin file to a .table file. Finally, execute the registration_admin command with
Registering Users
4-7
the process_table action. This procedure is described in detail in the command

description of registration_admin in Chapter 6, Command Overview.
In either case, the users directories and the links to them remain intact until manually
deleted.

To change information about a user who is already registered on the system, give the
registration_admin command. Select the update_user_info action and give
the users person_name. Screens that are similar to the ADD NEW USER screens will
appear. Any value, including Password, may be changed, although the password is
not displayed. The state of the users account is shown in the fields Terminated and
Number Login Violations. If a users account has been terminated because of
login violations, change the value of Terminated to no and Number Login
Violations to 0.
If a password change is needed or if a user account needs to be reinstated after
excessive login violations, use the registration_admin command or the
set_registration_info command to change the password. Note that the
set_registration_info command has a better performance time. For more
information on these commands, see Chapter 6, Command Overview.
You cannot change the password of a user who is registered with a password type
of external (for example, the user is registered to use an external authentication
service). VOS never terminates the account of such a user.
If the Name or first Groups value is changed, be sure to rename directories and links
and update access lists using the propagate_access command. For more
information on this command, see VOS Commands Reference Manual (R098). When
new group names are added, links to the users home directory must be created
manually. If the Home Directory value is changed, creation of the new home
directory and any changes desired for the old and new directories such as copying files
or directories, creating links, and giving access, must be performed manually.
NOTE
User records cannot be updated as a batch process with
the registration_admin command; they can only be
added or deleted.
4-8

To list the users registered on your system, use the registration_admin command
and select the list_registered_users action. A screen displays all the users
registered on your system and the first group to which each is assigned. For more
information about this command, see Chapter 6, Command Overview.

If a user who is registered with a password type of VOS changes his or her password,
and then is unable to remember the new password, use either the
set_registration_info command or the registration_admin command to
give the user a new password. The set_registration_info command is preferred
because its performance time is faster.
If a user who is registered with a password type of external forgets his or her
password, you must use the facilities provided by the external authentication service to
reset the password.
Security
Whenever the databases are updated, the name of the person responsible and the
time of the modification are entered in the master record of
change_password.sysdb. This information is also entered in the security log.
Restricting Passwords
You cannot restrict the passwords used by users registered with external passwords.
You can restrict the ability of users registered with a VOS password to select their own
password using the following methods.
Use the set_password_security command to restrict classes of characters
and types of words from being used in a password.

Use the forbidden_passwords.table file to restrict specific words from being
used as a password.
These methods are optional and non-exclusionary, so you can set password
restrictions on a system using one method, both methods, or neither method.
The set_password_security command is documented in Chapter 6, Command
Overview. Use it to restrict classes of characters from being inserted in a password.
Registering Users
4-9
For example, to prevent vowels from being included in passwords on module m5, enter
the following command:
set_password_security m5 -forbid_vowels
To prevent specific words from being used as passwords, create a
forbidden_passwords.table file. The fields in this file are defined in the
forbidden_passwords.dd file. The contents of forbidden_passwords.dd,
which you must never modify, follow:
index:
password
no_duplicates no_null_keys;
fields:
password
char (32) var;
end;
The forbidden_passwords.dd file is stored in the
(master_disk)>system>configuration directory. To create a
forbidden_passwords.table file, perform the following steps:
1. Select the words to forbid from being passwords. Enter the restricted words in a file
named forbidden_passwords.tin in the following format:
/* %sales#m1>system>configuration>forbidden_passwords.tin
*/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
=password
=password
=password
=password
=password
=password
=password
=password
=password
=password
=password
=password
=password
=password
=password
password
Password
PASSWORD
login
Login
LOGIN
marketing
Marketing
MARKETING
sales
Sales
SALES
widget
Widget
WIDGET
Since passwords are case sensitive, judge how many versions of each forbidden
word to include. For example, while this password file forbids use of the words
password, Password or PASSWORD, the word PaSsWoRd is still permissible.
4-10
2. Save the forbidden_passwords.tin file and issue the following command to

create the forbidden_passwords.table file:
create_table forbidden_passwords
3. Broadcast the file:
broadcast_file forbidden_passwords.table
>system>configuration
4. To enable the forbidden_passwords.table file on the %sales#m1 module,
invoke the set_password_security command as follows:
set_password_security %sales#m1
-forbid_passwords_in_table
See the description of the set_password_security command in Chapter 6,
Command Overview, for more information on enabling forbidden passwords.
Compatibility
Although the create_registration_table command is now obsolete, the current
release still supports it so that you can maintain the pre-Release 10 registration
database when the registration_admin command is used to add new users.
If you want to use the create_registration_table method of registering users,
you must also use the log_registered_users command. This command extracts
all user data from user_registration.sysdb and re-creates the
registration_file.tin file in the directory >system on the master module. The
log_registered_users command also updates the master record in
change_password.sysdb in the directory >system on the master module.
Once you have issued the log_registered_users command, you can edit the
registration_file.tin file and issue the create_registration_table
command. See the description of the log_registered_users command in
Chapter 6, Command Overview.
Registering Users
4-11
Updating the Registration Database

When you change either your system name or the name of a module in your system,
any home directory path names in the registration database that contain the old name
are no longer valid, and must be updated. Change them one at a time with the
registration_admin command, or use the following steps to make the changes
globally.
NOTE
If registration_file.tin is copied from another
system, you will also need to copy that systems
change_password.sysdb file.
1. Invoke the log_registered_users command, described in Chapter 6,
Command Overview, to create the file registration_file.tin in the
directory (master_disk)>system>configuration.
2. Edit the registration_file.tin file to update all affected home directory path
names.
3. Invoke the create_registration_table command to re-create the database
with the revised data.
NOTE
Since create_registration_table re-creates the
entire registration database, it takes a substantial period
of time to execute. Use this method during a period of light
usage.
This procedure should always be performed as part of the series of steps in renaming
either a module name or a system name. Changing a module or system name is
described in VOS System Administration: Administering and Customizing a
System (R281).
4-12
Chapter 5
Managing Security
5-
This chapter describes the tools for managing security on modules. Sections include:
System Auditing
RADIUS Support

The operating system security logging facility keeps a log on each module of attempted
access violations by users on the module. The security log for each module is the file
>system>security_log.(date).
An access violation is an attempt by a user to do any of the following:
use a file, directory, or device in a way not allowed according to the users access,
as defined by the appropriate ACL or DACL.

gain access to the system using an invalid password. Every instance of an
incorrect password is logged.

gain access to the system using a group name not in the users registration record.
gain access to a system as a privileged user when the user does not have
privileged access.
gain access to a system using a home directory path name that is neither the users
default nor the path name stored in the users registration record or when the
no_home_dir_change flag is on in the users registration record.
gain access using a subsystem that is not in the users registration record.
Managing Security
5-1

gain access to a system using a priority higher than the value of max_priority
in the users registration record.

gain access to the system when the users account has been terminated.
gain access to a file, directory, or device on another system without fulfilling the
requirements of that systems network access table.

log in to another system on which the user is not registered.
log in to another system using a password other than the one required in that
systems password database.

issue a privileged s$ entry without being privileged.
issue a privileged command to the Overseer without being privileged.
NOTES
1. If a user attempts to access a target system from a
local system that is not listed in the target systems
network_access.tin file, this is treated as a
security violation and is logged to both the local
system and the target system. For example, if a user
invokes the pre-login command list_systems on
the remote system, the security violation will be
written to both the local and the remote security logs.
2. The login command and the Streams TCP FTP
Daemon specify in their messages that they write to
the system security log when a denial of access is due
to a failure to obtain a satisfactory result from an
external authentication service.
Messages are never displayed to the users that
indicate the reason for a failed authentication attempt.
The security logging facility includes two commands.
This command displays notification on a specified terminal whenever an entry is
added to security_log.(date).
security_admin
This command enables and disables security logging on any module in the system.
These commands are documented in Chapter 6, Command Overview.
5-2
Security Log Message Format

Messages appearing in the security_log.(date) file have the following format:
n: date time user_name terminal_name
Event: event_type Status: status
Target: process_name
Text: error_message_text
Process ID: process_id
Descriptions of the variables in the security_log.(date) messages follow:

n
The number of messages logged since the last time the security_admin
command enabled security message logging. If security logging is halted and
restarted during the same day, the newer messages are appended to the existing
security_log.(date) file, and the message numbering restarts with
number 1.
date time
The date and time the security violation occurred.
user_name
The user name of the process originating the security violation.
terminal_name
The origination terminal of the security violation.
event_type
The type of event. The possible values are ADMIN, CHANNEL, CONFIGURATION,
IO, OBJECT, PERFORMANCE, PRINT, PROCESS, SECURITY, UTILITY, and
ACCESS. See the section System Auditing later in this chapter for more
information on event types. This information is displayed only when audit_admin
-display long is invoked.
status
The success or failure of the event. The possible values are SUCCESS and
FAILURE. This information is displayed only when audit_admin -display
long is invoked.
process_id
The process ID of the calling process. This information is displayed only when
audit_admin -display long is invoked.
process_name
The name of the process that the user attempted to modify.
error_message_text
The text of the error message describing the security violation.
Managing Security
5-3
Here are some typical security violation messages from a security_log.(date)

file that had been created by invoking audit_admin access -audit -display
short:
222:
95-05-27 09:07:30 EDT ckb.* %pgh#term.10.4.2

Target: login ckb.* -module %pgh#m10
Text: not registered on module. ckb
223: 95-05-27 13:21:14 EDT Amy_Charma.Hardware

%pgh#term.10.14
Target: login Amy_Charma.Hardware -module %pgh#m10
Text: Wrong password.
224:
95-05-27 13:50:20 EDT auser.Guest %pgh#term.10.8

Target: #cad_db>locale>us_english
Text: Status permission to directory is required.
check_access
login Command Error Messages
The login command error messages are logged to the security_log.(date) in
the following situations.
If the login command is unable to communicate with the VOS RADIUS
Authentication Server because the server queues are missing. A message similar
to the following is logged:
201: 01-01-18 08:23:15 est Joe.Stratus %es#abc_login.m123
Stopped 01-01-18 08:23:56 est occurred 3 times.
Target: login Joe.Stratus -module %es#m77
Text: Object not found. External Authentication server
+unavailable.
If the login command is able to communicate with the VOS RADIUS
Authentication Server, but receives back a denial. A message similar to the

following is logged:
205:
5-4
01-01-18 08:28:36 est Joe.Stratus %es#abc_login.m123

Text: External authentication server denied user.

If the login command is able to place a message into the server queue but does
not receive a response before the time-out period expires. A message similar to the
207:
01-01-18 08:50:03 est Joe.Stratus %es#abc_login.m123

Text: Timeout period has expired. External
+authentication server unavailable.
FTP Daemon Error Messages

The FTP Daemon error messages are logged to security_log.(date) in the
following situations.
If the FTP Daemon is unable to communicate with the VOS RADIUS Authentication
Server because the server queues are missing. A message similar to the following
is logged:
Stopped 01-01-18 08:23:56 est occurred 3 times.
Target: FTP login failed from Joe.stratus.com
Text: Object not found. 530 Login incorrect External
+Authentication server unavailable.
If the FTP Daemon is able to communicate with the VOS RADIUS Authentication
Server, but receives back a denial. A message similar to the following is logged:
Text: 530 Login incorrect. External authentication
+server denied user.
If the FTP Daemon is able to place a message into the server queues but does not
receive a response before the time-out period expires. A message similar to the
Text: Timeout period has expired. 530 Login incorrect.
+External authentication server is unavailable.
See VOS Codes and Messages Reference Manual (R132) for more information about
messages.
Managing Security
5-5
System Auditing
System Auditing
VOS permits the selective audit of types of events, users and objects. The
audit_admin command enables and disables selected event audits for a module. All
audits are recorded on the module owning the subject process.
There are two categories of event classification: selectable and non-selectable
(default). Default events are logged automatically to the log files, regardless of the
modules audit state. All default system events are logged to the
syserr_log.(date) file, all default access and security events are logged to the
security_log.(date) file. All selectable events are logged to the
security_log.(date) file.
Event Types
The following default auditable events record information about system security
activities:
process creation and deletion
selected administration changes
system configuration changes
selected system performance changes.
The following selectable auditable events provide more specific system information:
file, link, and directory creation and deletion
device addition and deletion
program initiation
miscellaneous administration and security access control.
5-6
System Auditing
Table 5-1 lists the event types, the commands associated with each event type, and
whether the event is selectable or default.
Table 5-1. Event Types
Event Type
Auditable Commands, Subroutines, and Operation
syserr default
syserr_log.(date)messages
process default
s$set_priority, process creation, process termination
admin default
login_admin and logout_admin overseer operation
configuration
default
bootload disk initialization/reload, disk recovery, cancel of disk retry, physical

volume setup/removal, logical volume dismount/expansion/mount/salvage,
dump_disk, format_disk, cancel_fast_disk_recovery,
initialize_boot_disk, initialize_disk,
initialize_duplex_disk, initialize_pick_boot_disk,
initialize_pick_disk, reload_disk, select_duplex_disk,
set_default_time_zone, uninitialize_disk
io selectable
s$close, s$create_file, s$create_dir, s$delete_file,

s$delete_file_on_close, s$delete_index, s$link, s$open,
s$rename, s$truncate_file, s$unlink
object selectable
s$close, s$delete_file, s$delete_file_on_close,

s$delete_index, s$give_access, s$open, s$remove_access,
s$rename, s$set_access_list, s$truncate_file
security selectable
execute-in-kernel program invocations, file system, process, and system

access violations
access selectable
s$give_access, s$give_default_access, s$remove_access,

s$remove_default_access, s$set_access_list,
s$set_default_access_list
Auditing Users and Processes

The audit_admin command governs the auditing of types of events. To audit the
events originating with specified processes and users, invoke the
set_process_audit command. The audit_admin process -audit command
must be invoked before process and user audits are logged to the security log.
Auditing Objects and Internal Commands

The set_object_audit command permits the auditing of files and internal
commands. As with the set_process_audit command, audit_admin object
-audit must be invoked before object audits are logged to the security log.
Managing Security
5-7
System Auditing
In addition to the set_object_audit command, there is an additional method of

setting auditing on internal commands:
1. change_current_dir (master_module)>system>configuration
2. Edit internal_commands.tin file.
3. Update an existing command record or add a new command record. To audit the
format_disk command, add the following lines to the
internal_commands.tin file:
/=name
=audit
format_disk
1
4. create_table internal_commands
5. copy_file internal_commands.table (master_disk)>system
6. change_current_dir (master_disk)>system
7. configure_commands
8. audit_admin object -audit
Event Entries in System Logs

Once auditing is enabled, the following information is recorded to the appropriate log
(syserr_log.(date), security_log.(date), or hardware_log.(date))
about each audited event:
date and time of the event
the unique identifier of the user/process/terminal generating the event
type of event
success or failure of the event
terminal identifier of the originating request
name of object introduced, accessed, or deleted from a users address space
description of modifications made to the user/system security databases.
This information varies depending on the use of the -format argument.

Event Messages in the syserr_log.(date) File
Audits enabled using -format long generate more information than audits enabled
with -format short. Here is typical output in a syserr_log.(date) file, when
audit_admin -format short has been enabled:
13:48:14 link 0100 i 31
10540 02 0000000D 00000000
controller status
13:48:45 overseer:Process Bill_Roy.Mfg (login) on #term.24.4
5-8
System Auditing
terminated due to inactivity.

13:48:48 Process 011451F2, Bill_Roy.Mfg (login), terminated.
13:49:58 link 0100 i 30
10463 01 00000091 00000000
controller status
13:50:52 Process 01145252, Ann_Bach.Mfg (login), created.
This output shows that invoking audit_admin -audit -format short does not
impact the syserr_log.(date) file. However, when audit_admin -format
long has been enabled, the messages in the syserr_log.(date) file contain
additional information:
11:20:46 link 0100 i 31 10540 02 00000011 00000000
controller status
SYSERR
{01142006 CPU0.Idle}
11:20:50 msg_control: Halted communication with system 185-0
Code = 2043
SYSERR
{01142020 Overseer.System}
11:24:01 audit event admin: all event logging changed from
ON to OFF.
ADMIN
SUCCESS {0114201B Overseer.System}
The additional information line contains an event type field (such as SYSERR or
ADMIN), a process name and number (such as Overseer.System) field. A status
field (denoted by the word SUCCESS or FAILURE) field may also appear in this line.
Event Messages in the security_log.(date) File
When audit_admin all -audit -format long has been enabled, the messages
in the security_log.(date) file contain additional information:
1:
95-05-26 11:11:48 EDT Wright.Mfg

Target: #Mfg2>system>tools_library
Text: Modify permission to directory is required.
(Continued on next page)
Managing Security
5-9
System Auditing
2:
3:
4:
5:
6:
7:
check_access
95-05-26 11:20:24 EDT Wright.SysAdmin %mfg#term.2.18
Event: IO
Status: SUCCESS Process ID: 01145238
Target: %mfg#m4>system>overseer.server_queue
Text: Closed port 8.
Event: IO
Target: %mfg#m4>system>command_library>audit_admin.pm
95-05-26 11:20:24 EDT Cathy_Foster.Mfg %mfg#term.4.1.2
Event: IO
Status: SUCCESS Process ID: 011451CD
Target:
%mfg#m4>system>postoffice>registration.global.sysdb
Text: Opened port 10, relative file, for dirty notify.
Event: IO
Target: %mfg#m2>Mfg>Cathy_Foster>_emacs.term.4.1.2
Event: IO
Target:
%mfg#Mfg2>system>tools_library>emacs_messages.text
Event: IO
Target:
%mfg#m2>system>postoffice>registration.global.sysdb
...
238:

Event: IO
Target: %mfg#m4>system>command_library>audit_admin.pm
Text: Opened port 7, fixed file, for input.
239: 95-05-26 11:24:01 EDT Wright.SysAdmin %mfg#term.2.18
Event: IO
Target: %mfg#m4>system>overseer.server_queue
Text: Opened port 8, server queue file, for requestor.
The additional information line contains an event type field (such as IO), a status field,
indicating the success or failure of the operation, and a a process ID field. When the
-format short argument is invoked, all the events are logged to this file without the
additional information line.
5-10
NOTE
Avoid specifying the all or io value unless the module
has a large amount of unused disk space in the system
directory. By specifying the io or all value, every I/O
event on the module is audited, meaning the
security_log.(date) file can become thousands of
blocks long within a few hours. In the previous example,
VOS logged 239 messages to the syserr_log.(date)
file in less than four minutes, almost all of them of the I/O
event type.

The ftpd daemon process arguments, -security_check_file, and
-allow_any_port, enable you to restrict access to your system from a user logging
in via FTP. For information about ftpd daemon, see the manual VOS STREAMS
TCP/IP Administrators Guide (R419). The description of the arguments are as follows:
-security_check_file security_file
This argument prevents unauthorized users from logging in to a remote host with
FTP. If you also specify the -log argument, the log file records the following
information.
if a user with null access attempts to log in via FTP
if the ftpd daemon process cannot find security_file
The value of security_file should be a path name to an empty file that will
become the security file. The access control lists on the security file control access
to the system via FTP. For example, if a user logging in via FTP has non-null access
to the file, the user is granted access to the system and can successfully log in. If
the user has null access to the file, the user receives an error message and the FTP
connection is terminated.
You can create a list of allowed users by setting null access for *.* and giving read
access for the specific users who are allowed access. You can create a list of
denied users by giving read access to *.* and setting null access to the list of
specific users who are denied access. You can specify users as
user_name.group_name, user_name.*, or *.group_name. The ftpd daemon
process determines access based on standard access-control-list processing as
described in the VOS Commands Users Guide (R089).
If the ftpd daemon process cannot find the security file, the user is denied access
to the system.
Managing Security
5-11
If you want to start the ftpd daemon process with security enabled, issue the
following command.
start_process -output_path (master_disk)>system>stcp>logs>ftpd.out
+(master_disk)>system>stcp>command_library>ftpd -security_check_file
+%se_j14#m14_d02>SW>Noah_Smith>ftp_security -privileged -process_name ftpd7
NOTE
Do not enter the plus (+) sign that appears in this
example; it is a line-continuation character.
-allow_any_port
&<&/(!
This argument checks that the IP address in the FTP protocol command PORT
matches the clients IP address. By default, ftpd does not perform this check.
The -allow_any_port argument provides protection against security breaches
by detecting:
Whether the TCP/IP address in the PORT command is not from the originator
Whether the PORT number is less than 1024
You can use the -allow_any_port argument with the following external
variables of the ftpd daemon process.
allow_any_port$This variable is set to 1 if you specify the
-allow_any_port argument. By default, it is set to 0. If you use proxy

servers, you must set this variable or the proxy servers will not function
properly.
warn_on_port_misuse$If this variable is set to 1 (the default) and an
incorrect PORT command is received when you are running ftpd, the following
message is returned.
refused PORT (TCP/IP_address) from (client_name)
warn_when_allow_port$If this variable is set to 1 (the default) and you
specify the -allow_any_port argument, the following message is returned.

Warning: ftpd invoked with -allow_any_port
You can use the set_external_variable command to set the preceding
external variables, as shown in the following example.
set_external_variable warn_on_port_misuse$ -in
>system>stcp>command_library>ftpd.pm -to 1 -type integer
5-12
For more information about the set_external_variable command, see the

VOS Commands Reference Manual (R098).

The set_password_security command enables you to set restrictions on the
format of user passwords. With this command, you may:
require the inclusion of both letters and numbers in a password
restrict classes of passwords, such as not allowing a user name
set the minimum number of hours between password changes
designate the module or system where these restrictions apply.
By default, all the restriction-setting arguments are turned off. After you specify
arguments to enforce the restrictions at your site, the new values remain in effect until
the module is rebooted. By including the set_password_security command, with
the applicable arguments specified in your module_start_up.cm file, the correct
password security controls will remain in place each time the module is rebooted.
These restrictions only apply to users registered with VOS passwords.
For more information, refer to the description of the set_password_security
command in Chapter 6, Command Overview, and see the description of the
forbidden_password.tin file in Chapter 4, Registering Users.

The login_admin command, documented in detail in Chapter 6 of this manual,
imposes and removes restrictions on user login to a module. This section describes the
three arguments that impose restrictions and the one argument that removes a
restriction.
The login_admin command can also be used to set a password expiration time, a
minimum password length, a maximum number of bad passwords, and a maximum
number of login attempts.
Limiting the Number of Users

The max_logins argument limits the number of users who can log in to the module
specified in the command. The maximum value is 1023. The following command limits
to 40 the number of users who can log in to the current module.
login_admin 40
Managing Security
5-13
This argument can be used to control the load on a modules resources. See VOS
System Administration: Administering and Customizing a System (R281) for load
control information.
Requiring a Special Password

The -password special_password argument requires each user to supply the
value special_password to log in. (As described previously, a user may also be
required by the registration database to supply his or her own password.)
This option sets up a special session to which only users who know the password,
called the special-session password, can log in. Administrative or test personnel can
then log in to the special session, while unauthorized users are denied access. The
following command sets up a special session on module #m9.
login_admin -module m9 -password wow
Preventing Specified Users from Logging In

The -restrict argument allows you to prevent individual users or groups of users
from logging in directly (but not through a subprocess) to the module. This argument is
useful for limiting a group from directly logging in to a module while administrative or
test personnel are working on that module. The following command prevents users in
the group Inventory from logging in to module #m12.
login_admin -module m12 -restrict *.Inventory
With the -list_restricted argument, you can display a list of users who are
restricted from logging in to a module.
Removing Login Restrictions

The -unrestrict argument lets you remove the restrictions for a specified user
name or a user star name. The following command removes for the current module the
restriction on logins formerly imposed on users in the group Inventory.
login_admin -unrestrict *.Inventory

The logout_admin command logs out inactive processes. It prevents terminals from
being both logged in and unattended or inactive for a specified time. Since the
operating system can identify processes that operate from a dialup line, these
processes may be logged out after being inactive for a specified time.
5-14

The (master_dir)>process_dir_dir is the process directory for any user whose
home directory resides on the module associated with the master disk. This directory
is used by some processes to store objects temporarily.
Sites requiring C2 security features must set strict access control on
(master_dir)>process_dir_dir. However, setting strict access on this directory
may interfere with some existing applications. To permit a smooth transition to strict
access on process_dir_dir, see the Software Release Bulletin: VOS
Release 14.4.0 (R914).
RADIUS Support
The VOS RADIUS Support permits the VOS System Administration to designate that
selected VOS users must be authenticated by an external RADIUS service, instead of
by VOS itself. VOS RADIUS Support, when used with a RADIUS service, permits an
organization to designate a single authentication service for multiple computer systems
from a wide variety of vendors, and permits these users to be authenticated using a
variety of methods:
static passwords
one-time passwords
combinations of static and one-time passwords
challenge-response passwords
combinations of static, one-time, and challenge-response passwords
When enabled, VOS RADIUS Support affects the behavior of the login command and
the STREAMS FTP daemon. User programs can also invoke VOS RADIUS Support to
validate user identities for an application environment.
NOTE
Stratus does not supply an external RADIUS
authentication service; you must obtain this service from
another vendor.
Managing Security
5-15
RADIUS Support
The following sections document how to install and use the VOS external Remote
Authentication Dial-In User Service (RADIUS).
Components
Configuration
User Registration
Components
This section describes the components that comprise VOS RADIUS Support.
Commands
The following two privileged commands are included with VOS RADIUS Support:
radius_adminThis command performs administrative functions.
radius_auth_serverThis command is the server that receives
authentication requests from VOS processes and communicates with an external
RADIUS authentication service.
For more information on these commands, see Chapter 6, Command Overview.
Configuration Files
Configuration information for VOS RADIUS Support is in a text file named
radius.tin, located in the directory (master_disk)>system>configuration.
The data description file, radius.dd, is located in the same directory. The VOS
create_table command is used to process these two files, which creates an output
file, radius.table. For information on the radius.tin file, see The radius.tin
Configuration File later in this section.
Include Files
The following files are included with VOS RADIUS Support, and are automatically
loaded with VOS:
(master_disk)>system>command_library>radius_auth_server.pm
(master_disk)>system>command_library>radius_admin.pm
(master_disk)>system>configuration>radius.sample.tin
(master_disk)>system>cofiguration>radius.dd
(master_disk)>system>include_library>ext_auth_message.incl.c
(master_disk)>system>include_library>ext_auth_message.incl.pl1
(master_disk)>system>object_library>perform_ext_auth.obj
5-16
RADIUS Support
Queues
VOS RADIUS Support uses two server queues for communication between client VOS
processes and the VOS RADIUS server. Since both of these queues are used to pass
messages that contain user names and passwords, be careful to set the proper access
to the users.
Subroutines
The following VOS subroutines are used in support of VOS RADIUS Support:
s$get_registration_infoThis subroutine returns registration information
for a specified user.
s$perform_ext_authenticationThis subroutine takes the information
necessary to authenticate a user using an external authentication service,
communicates with the authentication service, and returns the result to the caller.
For information about these subroutines, see Chapter 7, Subroutines.
Configuration
To configure your system for VOS RADIUS Support, you must copy or rename
>system>configuration>radius.sample.tin to radius.tin, and edit the file
to supply configuration information for your network.
The radius.tin Configuration File
The following is an example of the radius.sample.tin file:
=packet_timeout
=packet_retries
=multihosted
5
2
0
=primary_auth_ip
=primary_auth_port
=primary_auth_secret
127.0.0.1
9
primary_pass
=secondary_auth_ip
=secondary_auth_port
=secondary_auth_secret
127.0.0.1
9
secondary_pass
The following describes the fields in the radius.tin file needed to configure your
primary and secondary VOS RADIUS Service.
NOTE
If you do not have a secondary authentication server,
make the primary and secondary addresses the same.
Managing Security
5-17
RADIUS Support
packet_timeout N
The value for N is an unsigned integer that specifies the number of seconds a
transmit request waits for a RADIUS server to respond before failing over to the
other RADIUS server.
Upon receipt of a new authentication request, the VOS RADIUS server first
attempts to communicate with the primary RADIUS server. If no response is
received from the primary RADIUS server within the timeout period, VOS attempts
to communicate with the secondary RADIUS server. If no response is received
from the secondary RADIUS server within the timeout period, VOS again tries the
primary RADIUS server. This continues until the number of packet retry attempts
is exceeded; until the overall authentication timeout period is exceeded; or a
response is received from one of the two RADIUS servers.
NOTE
If neither RADIUS server responds within the configured
timeout values, no users who are registered to require
external password will be able to log in. This could
theoretically happen if the RADIUS servers are shared by
many hosts and they both get overloaded. Therefore, be
careful to choose an appropriate timeout value.
The minimum packet set timeout value is 1 second.
packet_retries N
The value for N is an unsigned integer that specifies the number of times that a
packet should be retransmitted to a RADIUS server. This value is in addition to the
initial transmission; thus, specifying the value of 2 allows for a maximum of 3
attempts to send each packet.
multihosted N
The value for N is an unsigned integer that specifies whether the primary and
secondary IP addresses represent two distinct RADIUS servers (non-multihosted),
or whether they represent two distinct IP addresses for the same RADIUS server
(multihosted).
In a non-multihosted configuration, VOS communicates with only one RADIUS
server (or IP address) at a time. Once it sends a packet to a RADIUS server at a
particular IP address, it only accepts a response from that same IP address. In a
multihosted configuration, VOS sends a packet to a specific IP address but accepts
a response from either IP address.
A value of zero specifies that the IP addresses represent distinct RADIUS servers.
A nonzero value specifies a single RADIUS server.
5-18
RADIUS Support
primary_auth_ip
primary_auth_port
primary_auth_secret
These fields represent, respectively, the IP address, UDP port number, and shared
secret for the primary RADIUS authentication server. You must change the
Stratus-supplied values to the ones that are appropriate for your configuration.
secondary_auth_ip
secondary_auth_port
secondary_auth_secret
These fields represent, respectively, the IP address, UDP port number, and shared
secret for the secondary RADIUS authentication server. You must change the
Stratus-supplied values to those that are appropriate to your configuration.
The IP address must be specified in numeric, dotted-quad form.
The following restrictions apply:
Do not use an invalid IP address; the VOS authentication server always uses
both addresses.
If you have two distinct RADIUS servers, you must specify the IP address of
each one; one as the primary server and one as the secondary server.
If you have a single RADIUS server that can be reached by two distinct IP
addresses, you must specify the IP addresses, one as primary and one as
secondary, and you must also specify a nonzero value for the multihosted
field.
If you have a single RADIUS server that can be reached only by a single IP
address, specify the same IP address as both the primary and secondary
address and specify a nonzero value for the multihosted field.
The UDP port number is an unsigned integer that specifies the well-known
port that the RADIUS authentication service listens to.
The shared secret is a character string that specifies an identification string
that ensures the security of transactions between a client (VOS) and a
RADIUS server. You must specify the shared secret for each server. When
the server is multihosted, only the primary shared secret is used; you need
not specify a secondary shared secret; even if you do specify one, it will be
ignored. The shared secret may be any length between 1 and 128 bytes.
NOTE
Per the RADIUS specification RFC 2138, the
radius_auth_server command will display a warning
message if the length of either of the shared secrets is
Managing Security
5-19
RADIUS Support
less than 16 bytes, as the standard deems this to be

insecure.
Once you have edited the radius.tin file, use the create_table command to
create the radius.table. Then use the broadcast_file command to broadcast
the radius.table to the (master_disk)>system>queues>ext_auth directory.
NOTE
You must create this directory before you run the
radius_auth_server command for the first time.
CAUTION
The contents of radius.tin and radius.table
contain sensitive information (the shared secret). Ensure
that only VOS System Administrators and VOS
Overseer.System processes have access to all copies
of these files.
When you purchase VOS RADIUS Support, the module_start_up.cm command
macro automatically starts the VOS RADIUS authentication server. If you did not place
a valid copy of radius.table into (master_disk)>system>queues>ext_auth
before you rebooted the module, you must restart the RADIUS authentication server
manually.
RADIUS Server Queues
VOS RADIUS Support creates the following two server queues for communication
between client VOS processes and the VOS RADIUS server the first time
radius_auth_server.pm is run:
(master_disk)>system>queues>ext_auth>ext_auth.server_queue
(master_disk)>system>queues>ext_auth>ext_chal.1.server_queue
The access control list (acl) for the server queues files are set as:
w
w
e
*.System
*.SysAdmin
*.*
NOTE
The radius_auth_server.pm command must be run
by a process that has write permission to both queue files.
You should never give general users read or write
5-20
RADIUS Support
permission to the queues as user names and passwords

of other users can be viewed.
You may also pre-create these server queue files.
User Registration
This section describes user registration for the VOS RADIUS Service. Sections
include:
Valid User Names
Valid Passwords
Valid User Names

VOS permits a wide variety of ASCII characters to appear in a user name. The RADIUS
standard (RFC 2138) makes no particular restrictions on characters that can appear in
a user name. Some RADIUS implementations may impose restrictions on the
characters that can appear in a user name, and may be insensitive to case.
You must ensure that all VOS user names are compatible with the specific
implementation of the RADIUS service that you select; VOS RADIUS Support makes
no attempt to validate the user names prior to sending them to RADIUS. For
information on VOS user names, see User Names in Chapter 1.
Valid Passwords
VOS permits any text character to appear in a password. Passwords may be between
0 and 128 bytes. VOS passes these passwords unmodified and uninterpreted to the
RADIUS service.
The VOS user registration file located in >system>user_registration.sysdb
contains a password type attribute for each user. The password type can be set
to one of two values: VOS or external. Setting the password type value to VOS
indicates that the user is registered to use a traditional VOS static password. This is the
default for all users. Setting the password type to external indicates that the user
is registered to require authentication using an external service.
Managing Security
5-21
RADIUS Support
NOTE
Currently, the only external authentication service
supported by Stratus is the RADIUS authentication
service.
Using the registration_admin command, you can change the registration
information, including the password type attribute, for any existing user at any time.
The change takes effect as soon as the new copy of the registration file is broadcast to
all modules in the system. You can register a new user with either password type value.
Once a user is registered to require external authentication, he or she can no longer
change their password from VOS, nor can you use the set_registration_info
command to change the password. You must use the facilities provided by the RADIUS
authentication service.
VOS obeys the instructions of the external authentication service, and either accepts
or denies access to the user accordingly. Therefore, VOS does not validate external
passwords, nor does VOS expire the password of a user registered for external
authentication. VOS never terminates the account of a user having too many
consecutive bad passwords, as VOS expects that all such administrative measures are
handled by the external authentication service.
When a user is registered to require external authentication, the VOS password
database (user_password.sysdb) still contains his or her VOS static password. If
you need to re-register a user to use VOS authentication, invoke the
registration_admin command and cycle the password type option to VOS.
Then, if needed, you can use the set_registration_info command to change the
VOS password.
Users who are registered to require VOS authentication are subject to the usual VOS
policies in regard to password expiration, account termination, valid passwords and so
on.

This section lists the various messages displayed by the VOS RADIUS authentication
server (radius_auth_server.pm) when the -log_level control argument to
radius_auth_server is set to basic, major, or detail.
5-22
RADIUS Support
The basic Level Messages

Messages similar to the following examples are displayed in the output file (or in the
system error log when -syserr is used) by the VOS RADIUS authentication server
when the -log_level is set to basic.
OperationStart up message
Radius authentication server starting up.

OperationShutdown message
Radius authentication server logging out.

OperationDisplay Current Configuration
Current configuration:
send timeout:
send retries:
multihosted:
primary server IP:
primary server port:
secondary server IP:
secondary server port:
5
2
1
192.168.223.214
1812
192.168.223.214
1812
Current globals:
auth_timeout$ = 60
log_level$ = 3
max_sockets$ = 10
syserr_option = 0
OperationInitialization Failure
Unable to reinitialize. Abnormal termination. Code EC.

OperationCreated server queue
Created QUEUE_PATH and set access.

AdministrationAccepted refresh configuration
Accepted refresh config request from PERSON.GROUP

[HEX_PID].
AdministrationRejected refresh configuration
Ignored refresh config request from PERSON.GROUP

[HEX_PID]. Code %EC.
Managing Security
5-23
RADIUS Support
AdministrationAccepted logout request
Accepted logout request from PERSON.GROUP [HEX_PID].

AdministrationAccepted statistics request
Accepted statistics request from PERSON.GROUP [HEX_PID].

The major Level Messages
The following messages are displayed in the output file (or in the system error log when
-syserr is used) by the VOS RADIUS authentication server when the -log_level
is set to major.
AdministrationRejected request
Ignored invalid admin request from PERSON.GROUP [HEX_PID].

AuthenticationDenial
Request from NAME [HEX_PID-HANDLE] Denied for user

PERSON.WHY
AuthenticationIgnored invalid request
Ignoring invalid message ID from PERSON.GROUP [HEX_PID].

Ignoring message ID from PERSON.GROUP [HEX_PID]. In wrong

queue.
AuthenticationSpecial handling of request
Request from PERSON.GROUP [HEX_PID] reuses handle [HANDLE}

of pending request for user PERSON_NAME.
Challenge response received from PERSON.GROUP [HEX_PID]

without pending challenge.
Challenge response received from PERSON.GROUP [HEX_PID]

but challenge not requested.
5-24
RADIUS Support
The detail level Messages

The following messages are displayed in the output file (or in the system error log when
-syserr is used) by the VOS RADIUS authentication server when the -log_level
is set to detail.
AuthenticationAcceptance
Request from NAME [HEX_PID-HANDLE] accepted for user

PERSON_NAME.
AuthenticationChallenge
Request from NAME [HEX_PID-HANDLE] challenged for user

PERSON_NAME.
OperationLoad control messages
Now listening to challenge queue only.

Now listening to both queues.
OperationLoad control messages
Max socket limit reached.

No longer at max socket limit.

Use the following test procedure to ensure that the external RADIUS authentication
service you have selected is compatible with VOS and supports all of the authentication
combinations that VOS supports:
1. Register Test Users on VOS
Use the VOS registration_admin command to register the following test
users with the password and password type shown in the following table.
User Name
Password
Password Type
test_vp
test_vp
VOS
test_np
test_np1
External
test_sp
test_sp1
External
test_otp
test_otp1
External
test_sp_otp
test_sp_otp1
External
Managing Security
5-25
RADIUS Support
User Name
Password
Password Type
test_np_crp
test_np_crp1
External
test_sp_crp
test_sp_crp1
External
Exit from the registration_admin command and wait for the updated
registration information to broadcast to all of the modules in the system. Be sure to
check the logs for any unusual messages.
2. Register Test Users on RADIUS
Using the administrative interface (supplied by the RADIUS server vendor) to the
RADIUS server, register the following users on RADIUS with the password shown
in the RADIUS Password column and Password Type shown in the last column.
NOTES
1. The following explanation uses the terminology of the
demo tokens.
2. Do not register test_vp on the RADIUS server.
3. Use this testing facility of the RADIUS server to
ensure that the test users are properly registered and
that you know their password values.
User Name
RADIUS Password Type
RADIUS Password
test_np
null password
<newline>
test_sp
static password
test_sp
test_otp
one-time password
OTP
test_sp_otp
static password concatenated

with one-time password
test_spOTP
test_np_crp
null password, then a

challenge/response password
<newline>
[Challenge]Response
test_sp_crp
static password, then a

challenge/response password
test_sp
[Challenge]Response
3. Ping the RADIUS Server from VOS

Use the ping command to verify that the RADIUS servers are accessible from
VOS. You should use the IP values specified in
5-26
RADIUS Support
>system>configuration>radius.tin. If the primary and secondary IP

addresses are different, be sure to ping both of them. If you do not receive a
response to the pings, you have either specified the wrong IP address, or you have
a network topology problem that is preventing VOS from bidirectional
communication with the RADIUS server. Please contact your network support
center for assistance.
4. Configure and Start the VOS RADIUS Authentication Server
Configure the radius.tin file and start the VOS RADIUS authentication server
as described in the Configuration section earlier in this Chapter. Use the -log
detail control argument to the radius_auth_server command so that all
acceptances and denials of authentications requests are reported.
5. Start the RADIUS Server Console Program
Using the procedures defined by the supplier of your RADIUS server, start up the
console and set the logging mode to display both acceptances and rejections.
6. Test the login Command
Perform the following VOS login commands. Each test should end with the
indicated result. If it does not end as expected, please contact the CAC.
The term null indicates that you should enter a blank password. The term OTP
indicates that you should enter a one-time password using a password generation
token. The term CR indicates that you should enter a response to the challenge that
is displayed. All other passwords should be entered exactly as shown.
Test
User Name
First Password
Second
Password
Expected Result
on VOS
Expected Result
on RADIUS
test_vp
badpw
NA
login incorrect
no message
test_np
test_np1
NA
login incorrect
bad static pw
test_sp
test_sp1
NA
login incorrect
bad static pw
test_otp
test_otp1
NA
login incorrect
bad static pw
test_sp_otp
test_sp_otp1
NA
login incorrect
bad static pw
test_np_crp
test_np_crp1
badpw
login incorrect
bad static pw
test_sp_crp
test_sp_crp1
badpw
login incorrect
bad static pw
test_vp
test_vp
NA
login
no message
Managing Security
5-27
RADIUS Support
Test
User Name
First Password
Second
Password
Expected Result
on VOS
Expected Result
on RADIUS
test_np
(null)
NA
login
accepted
10
test_sp
test_sp
NA
login
accepted
11
test_otp
OTP
NA
login
accepted
12
test_sp_otp
test_spOTP
NA
login
accepted
13
test_np_crp
(null)
CR
login
accepted
14
test_sp_crp
test_sp
CR
login
accepted
15
test_np_crp
(null)
badpw
login incorrect
bad response
16
test_sp_crp
test_sp
badpw
login incorrect
bad response
17
test_np_crp
(null)
Note 1
login incorrect
denial
18
test_np_crp
(null)
Note 2
login incorrect
denial
NOTES
1. Let the login command wait at the prompt for the
second password for longer than the value specified
in the -timeout control argument of the
radius_auth_server command. The default
value for this control argument is 60 seconds.
2. Let the login command wait at the prompt for the
second password for longer than the
challenge/response timeout value of the RADIUS
server. For some RADIUS servers, this is 2 minutes.
Finally, run a test in which you attempt to log in the test_np_crp user from two
different terminal sessions simultaneously. The VOS RADIUS authentication
server can handle this case, but some RADIUS servers permit this type of login,
and some do not. The following sequence of lines represents the order in which
you should perform the steps:
a. Terminal 1: login test_np_crp
b. Terminal 1: Password? (enter a newline)
c. Terminal 2: login test_np_crp
d. Terminal 2: Password? (enter a newline)
e. Terminal 1: Challenge is [XXXX], enter response:
5-28
RADIUS Support
f. Terminal 2: Challenge is [YYYY], enter response:

g. Terminal 1: (enter proper response to XXXX challenge)
h. Terminal 2: (enter proper response to YYYY challenge)
If the user at either Terminal 1 or Terminal 2 is denied authentication, the RADIUS
server does not support simultaneous authentication attempts for a user registered
to use challenge/response passwords. You should note this restriction for the
benefit of your corporate help desk.
7. Test FTP Service
Each of the following tests of the VOS FTP Daemon should end with the indicated
results. If a test does not end as expected, please contact the CAC.
The term null indicates that you should enter a blank password. The term OTP
indicates that you should enter a one-time password using a password generation
token. The term CR indicates that you should enter a response to the challenge that
is displayed. Enter all other passwords exactly as shown.
Log in either to the same VOS module, or another VOS module, or to a completely
different computer system. Using the ftp command, open a session to the VOS
module that you want to test. Run each of the following tests in turn. Note that VOS
FTP does not support the challenge/response protocol, so you will never have a
chance to enter a second password.
Test
User Name
First Password
Expected Result
on VOS
Expected Result
on RADIUS
test_vp
badpw
login incorrect
no message
test_np
test_np1
login incorrect
bad static pw
test_sp
test_sp1
login incorrect
bad static pw
test_otp
test_otp1
login incorrect
bad static pw
test_sp_otp
test_sp_otp1
login incorrect
bad static pw
test_np_crp
test_np_crp1
login incorrect
bad static pw
test_sp_crp
test_sp_crp1
login incorrect
bad static pw
test_vp
test_vp
login
no message
test_np
(null)
login
accepted
10
test_sp
test_sp
login
accepted
Managing Security
5-29
RADIUS Support
Test
User Name
First Password
Expected Result
on VOS
Expected Result
on RADIUS
11
test_otp
OTP
login
accepted
12
test_sp_otp
test_sp[OTP]
login
accepted
13
test_np_crp
(null)
login incorrect
timeout
14
test_sp_crp
test_sp
login incorrect
timeout

The implementation of the VOS RADIUS protocol is based and tested on RFC 2138
Remote Authentication Dial In User Service (RADIUS), April 1977. This section uses
the terminology given in RFC 2138 to describe how VOS communicates with the
RADIUS server. For complete information on RFC 2138, see
http://www.ietf.org/rfc/rfc2138.txt.
NOTE
A newer version of the RADIUS protocol is defined by
RFC 2865. Stratus has not tested VOS RADIUS Support
for compatibility with RFC 2856.
VOS RADIUS Support dos not implement RADIUS Accounting.
Access-Request Packets
VOS sends an Access-Request packet to the RADIUS server containing the following
attributes:
5-30
Attribute
Description
User Name
The name of the user to be authenticated.
User Password
The password of the user to be authenticated.
NAS Identifier
The full name of the VOS module (for example %sys#m1).
NAS IP Address
The IP Address of the default host name of the current module.
NAS Port
Has the same value as the auth_type argument of the

s$perform_ext_authentication subroutine:
value 1 for login.
value 2 for ftp.
value 3 for RSN (not currently implemented).
value 4 for other.
RADIUS Support
You can configure the RADIUS server to accept or reject authentication requests
based on the values of these attributes. For example, you can require that
RADIUS-enable VOS users to log in from a specific module. You can prevent users
from using FTP, or you can create users that can only use FTP.
The RADIUS server responds with an Access-Accept or Access-Reject packet,
according to whether the authentication request is accepted or denied.
Access-Challenge
When a user is registered at the RADIUS server to require a challenge and response,
the RADIUS Server responds to the Access-Request packet with an Access-Challenge
packet. The Access-Challenge packet contains a Reply-Message attribute field and a
State attribute field. The VOS RADIUS Server passes the Reply-Message to its client
and waits for a response from the client. When the client replies back with the
response, VOS sends a new Access-Request packet to the RADIUS Server. This new
Access-Request packet contains the same attributes as the original packet including
the State attribute, but the response to the challenge replaces the original password.
The RADIUS Server will issue one of three responses: Access-Accept, Access-Reject,
or another Access-Challenge packet.
Restrictions
Some external RADIUS authentication servers do not permit the same person to
undertake multiple, near-simultaneous challenge/response authentication requests.
For example, if a user is registered to require the use of a challenge and response, and
attempts to log in to multiple sessions at the same time, some servers will deny the
earlier authentication attempt even if the correct response is given. The solution is for
such users to complete each authentication request sequence before starting a new
request.
Managing Security
5-31
RADIUS Support
5-32
Chapter 6
Command Overview
6-
This chapter documents two types of commands: administrator commands and system
process commands.
The administrator commands are given directly by system administrators. Most
commands are of this type.

The system process commands are rarely or never used outside of
module_start_up.cm files. These commands usually start service processes

for the module.
The following administrator commands are documented in this chapter.
accounting_admin
audit_admin
configure_commands
create_user_sysdbs
login_admin
logout_admin
notify_secrurity_violation
radius_admin
radius_auth_server
registration_admin
security_admin
set_object_audit
set_priority
set_process_audit
The following system process commands are documented in this chapter.

wait_for_overseer
Command Overview
6-1
accounting_admin
accounting_admin
Privileged
Purpose
The accounting_admin command enables or disables the logging of statistics for a
module and specifies the type of statistics to be logged.
Display Form
----------------------- accounting_admin -------------------------module:
-disable_accounting:
no
-port_accounting:
no
-log_commands:
no
-log_files:
no
-log_proc_stats_records: yes
-log_proc_user_records:
yes
-log_transactions:
no
Command Line Form

accounting_admin module
-disable_accounting
-port_accounting
-log_commands
-log_files
-no_log_proc_stats_records
-no_log_proc_user_records
-log_transactions
Arguments
module
The module for which the accounting facility is being enabled or disabled. The
default is the current module.
&<&/(!
-disable_accounting
Disables accounting on the specified module. When disabling accounting, do not
use this argument with any other argument as new settings are ignored. When
6-2
accounting_admin
enabling accounting, set this argument to no to retain the other values. The default
value is no.
&<&/(!
-port_accounting
Records statistics about the I/O traffic on each port on the designated module. The
default value is no. This argument is automatically set to yes when the
-log_files argument is set to yes. Port accounting degrades system
performance slightly.
&<&/(!
-log_commands
Logs the start and terminate records for each command executed. The default
value is no. Command logging degrades system performance noticeably.
-log_files
&<&/(!
Logs a file-close record whenever a file is closed. When this argument is set to
yes, the -port_accounting argument is set to yes. The default value is no. File
logging degrades system performance noticeably.
&<&/(!
-no_log_proc_stats_records
Does not log a process statistics record whenever a process calls the subroutine
s$log_resource_usage. The default value is yes.
-no_log_proc_user_records
&<&/(!
Does not log a process-defined record whenever a process calls the subroutine
s$log_process_record. This argument permits the creation of user-defined log
records. The default value is yes.
&<&/(!
-log_transactions
Logs a transaction record whenever a transaction starts, commits, or aborts. The
default value is no. Transaction logging can degrade system performance
noticeably, depending on the number of transactions.
Explanation
The accounting_admin command enables or disables statistic-logging for a module.
When accounting is enabled, process statistics and user-defined log records are
logged by default. Commands, port-use records, file-use records, and transactions
may also be logged.
Command Overview
6-3
accounting_admin
Examples
The following command logs the closing of any file on the current module and the
executing, committing, or canceling of any transactions on the current module. This
command disables the writing of process-defined records by the operating system.
accounting_admin -log_files -no_log_proc_user_records
-log_transactions
The following command disables accounting on module m1.
accounting_admin m1 -disable_accounting
Related Information
See VOS System Administration: Administering and Customizing a System (R281) for
definitions of the types of accounting records.
6-4
audit_admin
audit_admin
Privileged
Purpose
This command enables or disables the auditing of events on a module, and specifies
the types of events to be audited.
Display Form
---------------------------- audit_admin ----------------------------event:
-audit:
no
-display: no
-format:
-module: current_module
Command Line Form

audit_admin event_type
-audit
-display
-format format_type
-module module_name
Arguments
event_type
&<&/(!
Specifies the type of event to be logged. The possible values are admin,
channel, configuration, io, object, performance, print, process,
security, utility, access, all, and a blank. The default is a blank, which
does not select a type of event to be audited. The print value is reserved for
future use.
Two categories of events are classified: selectable and non-selectable (default).
Default events are logged automatically once system auditing is enabled.
Selectable events are logged at the sites discretion. All default events are logged
to the syserr_log.(date) file (even when auditing is not enabled) and all
selectable events are logged to the security_log.(date) file. See Table 5-1 in
Command Overview
6-5
audit_admin
Chapter 5, Managing Security, for a list of commands, subroutines, and tasks

associated with each event type.
NOTE
Avoid specifying the all or io value unless the module
has a large amount of unused disk space in the system
directory. By specifying the io or all value, every I/O
event on the module is audited, meaning the
security_log.(date) file can become thousands of
blocks long within a few hours.
-audit
&<&/(!
Enables auditing. The default is no, meaning auditing is disabled for the module.
-display
Displays the types of events currently being audited.
&<&/(!
&<&/(!
-format format_type
Specifies the type of format that events are displayed in. The values are short,
long, and a blank. The default is a blank, designating no change.
NOTE
When the format is changed, it is changed for all default
events and any discretionary event type being audited.
-module module_name
Specifies the module whose events are to be logged. The default is the current
module.
Explanation
The audit_admin command enables the auditing of specified system events and
provides enhanced system messages about these events. This command should be
included in the module_start_up.cm file, but may be invoked at any time. There are
two classes of auditable events: default and selectable. See Table in Chapter 5,
Managing Security, for a list of the auditable events and their related commands,
subroutines and tasks.
6-6
audit_admin
Examples and Sample Output

To display the types of events currently being audited, enter the following command:
audit_admin -display
event
state
===================================
admin
OFF
channel
OFF
configuration
OFF
io
OFF
object
OFF
performance
OFF
print
OFF
process
OFF
security
OFF
utility
OFF
access
OFF
The audit log format is SHORT.
To audit access events in a short format, enter the following command:
audit_admin security -audit -format short
tail_file >system>security_log.(date) -records 20
1:
95-06-21 13:52:37 EDT Paul_Stein.Edu %jk#term.1.3.2

Target:
%jk#m1>process_dir_dir>pd.011420.Paul_Stein>_aakbLxa+KaWnrj.
temp
Text: Paul_Stein.Edu given r access.
2:
95-06-21 13:52:46 EDT Foley.SysAdmin %jk#term.1.30

Target: %jk#m1>system
Text: Ed_Wright.* given n access.
3:
95-06-21 13:55:05 EDT Overseer.System

Target:
%jk#m1>system>postoffice>ltr210>1953A8D16601E738.letter_body
Text: Frieda_Foley..* given r access.
4:
95-06-21 13:56:03 EDT Foley.SysAdmin %jk#term.1.30

Target: %jk#m1>system
Text: Removed Ed_Wright.* access.
5:
95-06-21 13:58:04 EDT Brian_Welles.Edu %jk#term.1.9

Target:
Command Overview
6-7
audit_admin
%jk#m1>process_dir_dir>pd.01149227.Brian_Welles>_aaarkbLxa+K
aWnzi.
+temp
Text: Gerry_Welles.Edu given r access.
NOTE
Issuing audit_admin security -audit -format
short is equivalent to issuing security_admin on.
To audit all events on %bos#m1 and display the events in a long format, enter the
following command while logged in to %bos#m1:
audit_admin all -audit -format long
tail_file >system>syserr_log.(date)
09:17:37 audit event admin: all event logging changed from OFF
to ON.
09:17:56 link 0100 i 31 10540 02 00000011 00000000 controller
status
SYSERR
{0114201B Overseer.System}
09:17:59 link 0100 i 31 10540 02 00000011 00000000 controller
status
SYSERR
{01142015 Overseer.System}
09:18:08 Process 011421EC, Tony_Pella.Doc (edit), created.
PROCESS SUCCESS {011421E7 Tony_Pella.Doc}
09:18:13 Process 011421EC, Tony_Pella.Doc (edit), terminated.
PROCESS SUCCESS {0114201B Overseer.System}
09:18:17 Process 011421ED, Mora_Hebert.Comm (13/lock),
created.
To disable the auditing of all events on %bos#m1, enter the following command while
logged in to %bos#m1:
audit_admin all -format short
Related Information
See Chapter 5, Managing Security, and the documentation for the
set_object_audit and set_process_audit commands in this chapter.
6-8
configure_commands
configure_commands
6-
Purpose
The configure_commands command modifies the assignment of access lists for a
specified set of internal commands.
Display Form
--------------------------- configure_commands ------------------------commands_table: (master_disk)>system>internal_commands.table
Command Line Form

configure_commands internal_commands_table_path_name
Arguments
internal_commands_table_path_name
The path name to the table file containing a list of internal commands and their
associated access lists. The default value for this argument is
(master_disk)>system>internal_commands.table.
Explanation
The configure_commands command updates the assignment of access lists for
internal commands. Each specified command has its access determined by its
associated internal command access list. Any unspecified commands are associated
with the >system>acl>system_default access list by default. Each new access
list uses the same access as the system_default file.
The give_access and related access commands set access on the internal
command access lists, which, in turn, set the access for the associated commands. If
you do not supply a value for the access_list_name field, VOS creates the empty
access list file in (master_disk)>system>acl, giving the access list the name of
the internal command.
Execution of this command does not affect any existing internal command access lists.
If a command listed in the internal_commands.tin file has become obsolete,
Command Overview
6-9
configure_commands
delete the command name record from the file and follow the first procedure described
in the example section for updating the internal_commands.tin file. To keep the
internal_commands.table file in force across bootloads, add this command to the
module_start_up.cm file.
In addition to enabling access for internal commands, this command provides an
alternate method for enabling the auditing of internal commands. See the Examples
section for this procedure.
Examples
The following procedure assigns the access list display_acl to the command
display, enables auditing on the command, and sets internal access for that
command.
1. Edit the
(master_disk)>system>configuration>internal_commands.tin file
and make the command auditable, add the following lines:
/=name
=access_list_name
=audit
display
display_acl
1
2. create_table internal_commands
3. copy_file internal_commands.table
(master_disk)>system>internal_commands.table
4. configure_commands
This command creates the access list display_acl in >system>acl.
5. Change to the (master_disk)>system>acl directory. Set access on the
access list file display_acl, corresponding to the access desired for the
display command.
6. set_object_audit -internal_command display on
7. audit_admin object -audit
To assign the system default access list to the command move_file, edit the
(master_disk)>system>internal_commands.tin file and add the following
lines:
/=name
=access_list_name
6-10
move_file
system_default
configure_commands
To assign the access list rename to the command rename, add the following line to
the internal_commands.tin file:
/=name
rename
Related Information
See Setting and Displaying Access to Internal Commands in Chapter 3 for more
information about setting access on internal commands and the set_object_audit
command in this chapter for information on auditing internal commands.
Command Overview
6-11
create_user_sysdbs
create_user_sysdbs
6-
Purpose
This command creates the files and links needed to access the password and
registration databases to verify user names and passwords as users attempt to log in
to the system.
Invoke this command only once in the lifetime of a module, unless the master module
(defined in the master_module argument description) is changed.
Display Form
-------------------------- create_user_sysdbs -------------------------master_module:
module:
Command Line Form

create_user_sysdbs master_module module_name
Arguments
master_module
Required
The module designated to broadcast registration changes to the other modules in
the system.
module_name
Required
The module to receive the registration changes from the master module.
Explanation
Give this command once for every module in the system. For example, in a system with
three modules, give this command three times and in one of the commands, specify
the master module in both arguments. In a single module system, give this command
once, giving the module name in both arguments.
6-12
create_user_sysdbs
When a user changes his or her password with the -change_password option of the
login command, the operating system first updates the users password information
on the master module, and then broadcasts the change to every other module.
The files created by this command are:
change_password.sysdb, created in the directory >system>configuration
on the master module, the directory >system on the master module, and the
directory >system on the module named in the module argument.
user_registration.sysdb, created in the directory
>system>configuration on the master module, the directory >system on the

master module, and the directory >system on the module named in the module
argument.
The links created by this command are:
master_password.sysdb, created on the master module. This link points to the
file change_password.sysdb in the directory >system>configuration on

the master module.
master_password.sysdb, created on the module named in the module
argument. This link points to the link master_password.sysdb on the master

module.
Examples
These commands create password files, registration files, and links on all of the
modules in a system.
create_user_sysdbs
create_user_sysdbs
create_user_sysdbs
create_user_sysdbs
m1
m1
m1
m1
m1
m2
m3
m4
Related Information
See Chapter 4, Registering Users, and the commands registration_admin and
set_registration_info.
Command Overview
6-13
Privileged
Purpose
This command displays all of the VOS registration information for a user.
Display Form
----------------------- display_registation_info -------------------user_name:
-module:
Command Line Form

display_registration_info user_name
-module module_name
Arguments
user_name user_name
Required
Specify the name of the user whose registration information should be displayed.
-module module_name
Specify the module name of the user registration database that should be used.
Explanation
This command displays all of the VOS registration information for a user. Some fields
are ignored for users who are registered for external authentication; this command
displays these fields as ignored or irrelevant.
6-14
Examples
The following example shows the output for a user who is registered to require external
authentication.
display_registration_info JoeStratus
Registration information for JoeStratus:
Account status
: active
Password type
: external
No password change
: forced true
Permanent password
: ignored
Must change password
: ignored
Min password length
: irrelevant
Date of last password chg : irrelevant
Max bad login attempts
: irrelevant
Number bad login attempts : irrelevant
Valid password expires
: irrelevant
Password grace time
: irrelevant
Password format
: irrelevant
Privileged
: true
Default Privileged
: true
Must Have Start Up Program : false
Must Use Subsystem
: false
No Home Dir Change
: false
Priority
: 5
Max Priority
: 7
Max Processes
: 0
Home Dir
: %ab#lang>Languages>Joe
Group (1)
: Stratus
Group (2)
: Languages
Group (3)
: SysAdmin
Group (4)
:
Group (5)
:
Subsystem (1)
:
Subsystem (2)
:
Subsystem (3)
:
Language
:
UID
: 385
GID (1)
: 172
GID (2)
: 134
GID (3)
: 2
GID (4)
: -1
GID (5)
: -1
Command Overview
6-15
The following example shows the output for a user who is registered to require VOS
authentication.
display_registration_info LisaStratus
Registration information for LisaStratus:
Account status
: active
Password type
: VOS
No password change
: false
Permanent password
: false
Must change password
: false
Min password length
: 1
Date of last password chg : 01-03-25
Max bad login attempts
: 0
Number bad login attempts : 0
Valid password expires
: never
Password grace time
: 0
Password format
: any
Privileged
: true
Default Privileged
: true
Must Have Start Up Program : false
Must Use Subsystem
: false
No Home Dir Change
: false
Priority
: 5
Max Priority
: 7
Max Processes
: 0
Home Dir
: %ab#lang>Languages>Lisa
Group (1)
: Stratus
Group (2)
: Languages
Group (3)
: SysAdmin
Group (4)
:
Group (5)
:
Subsystem (1)
:
Subsystem (2)
:
Subsystem (3)
:
Language
:
UID
: 386
GID (1)
: 172
GID (2)
: 134
GID (3)
: 2
GID (4)
: -1
GID (5)
: -1
6-16
Privileged
Purpose
This command enables sites to register new users with either the
create_registration_table command or the registration_admin
command.
Display Form
------------------------- log_registered_users ------------------------No arguments required. Press ENTER to continue.
Command Line Form

Explanation
The log_registered_users command provides registration file compatibility for
sites that use both the registration_admin and the
create_registration_table commands. The log_registered_users
command extracts all user data from user_registration.sysdb and re-creates a
registration_file.tin file in the directory
master_module>system>configuration. The file contains entries, including the
value of the external_authentication attribute, for all users registered with either
the create_registration_table command or the registration_admin
command.
When the log_registered_users command re-creates the
registration_file.tin file, it restricts access so that only members of the
SysAdmin group can modify it. Users not in that group need to get access to the file
before they can modify it. After editing the file, update the registration database using
the create_registration_table command.
No password data is written to the registration_file.tin file. Passwords are
stored in the change_password.sysdb databases. The log_registered_users
command updates change_password.sysdb in
master_module>system>configuration.
Command Overview
6-17
If you use the create_registration_table command, the

registration_admin.dd file must be installed in
Related Information
See Chapter 4, Registering Users.
6-18
login_admin
login_admin
Privileged
Purpose
The login_admin command sets login parameters for a module for the current
bootload.
Display Form
---------------------------- login_admin ---------------------------1 023
max_logins:
-module:
current_module
-password:
-restrict:
-unrestrict:
-list_restricted:
no
-delay_prelogins:
yes
-password_exp_time:
0
-min_password_len:
1
-max_access_attempts:
0
-max_bad_logins:
0
-subproc_logout_message:
no
-password_grace_time:
0
-password_format:
any
-terminal_as_process_name: no
Command Overview
6-19
login_admin
Command Line Form

login_admin [max_logins
-module module_name
-password special_password
-restrict user_name
-unrestrict user_name
-list_restricted
-no_delay_prelogins
-password_exp_time days
-min_password_len minimum_password_length
-max_access_attempts maximum_access_attempts
-max_bad_logins maximum_bad_logins
-subproc_logout_message
-password_grace_time password_grace_time
-password_format password_format
-terminal_as_process_name
Arguments
NOTE
The values displayed by this command are the same as
the values set by the login_admin command in the
module_start_up.cm file or by the most recent
invocation of the command.
max_logins
Specifies the maximum number of users who can be logged in to the module. The
value for max_logins can be any number from 1 to 1023. The initial default value
is 1023.
-module module_name
Specifies the module whose login parameters are being set. The initial default
value is the current module.
-password special_password
Prompts users for a special-session password. Only users who supply
special_password in response to the prompt are logged in to the module. This
argument permits the creation of a special session to which only administrative
or test personnel can log in.
6-20
login_admin
-restrict user_name
Adds a user name or user star name to the restricted users list. This user is
restricted from logging in to the module directly (but not through a subprocess). Do
not give this argument and the -unrestrict argument simultaneously. If you
omit both this argument and the -unrestrict argument, the current restricted
users list does not change. To display the restricted users list, invoke the
-list_restricted argument.
-unrestrict user_name
Removes a user name or user star name from the restricted users list. This user is
no longer restricted from logging in to the module. Do not give this argument and
the -restrict argument simultaneously. If you omit both this argument and the
-restrict argument, the current restricted users list does not change. To display
the restricted users list, invoke the -list_restricted argument.
&<&/(!
-list_restricted
Displays the restricted users list. The initial default value is no.
-no_delay_prelogins
&<&/(!
Does not check for processes attached to terminals connected to the module every
30 seconds and does not prevent the starting of a pre-login process for any
terminal until no other process is attached to that terminal. The initial default value
is yes. If this argument is set in the module_start_up.cm file, the displayed
value is the same as the value set in the module_start_up.cm file.
A pre-login process is a process that the Overseer starts for a terminal for which
login processes are enabled.
-password_exp_time days
Specifies how many days a password remains valid. A nonzero value for
password_expiration_time sets the number of days a password remains
valid. A value of 0 turns off the expiration check so that there is no limit on how long
a password remains valid. The initial default value is 0. If this argument is set in the
module_start_up.cm file, the displayed value is the same as the value set in
the module_start_up.cm file. Note, this argument only applies to users
registered with VOS passwords.
When you specify a nonzero value, the login_admin command displays the following
message upon login:
WARNING: All users who have not changed their passwords
since date/time will not be able to log in.
The date/time shown in the message is the most recent date and time that a user
would have had to change his or her password in order for it to be remain valid. This
helps to remind users to change their passwords regularly.
Command Overview
6-21
login_admin
For example, if on June 30, the system administrator specifies 7 as the number of
days a password is valid, the login_admin command would display this
message:
WARNING: All users who have not changed their passwords
since 94-06-23 11:05:15 EDT will not be able to log in.
Users who had not changed their passwords in the last seven days would be
unable to log in. This argument should be used with the
-password_grace_time argument, to control the grace period before users lose
their account privileges.
-min_password_len minimum_password_length
Specifies the minimum number of characters that can comprise a password. This
field is checked only when the user specifies -change_password at login. The
value of minimum_password_length can be any number from 1 to 32. Note, this
argument only applies to users registered with VOS passwords. The initial default
value is 1.
-max_access_attempts maximum_access_attempts
Specifies the maximum number of consecutive unsuccessful login attempts that
can be made on a terminal. When the maximum is reached, the Overseer briefly
disconnects the terminal. A nonzero value for maximum_access_attempts
restricts the number of attempts to the specified number. A value of 0 turns off the
checking for login violations for each pre-login process. The initial default value is
0.
-max_bad_logins maximum_bad_logins
Specifies the number of consecutive login failures a user can have before his or
her account is terminated. A nonzero value for maximum_bad_logins terminates
the users account after the specified number of consecutive login failures. A value
of 0 turns off the checking for login violations for each user account. Note, this
argument only applies to users registered with VOS passwords. The initial default
value is 0.
&<&/(!
Sends a message to any user logged into a subprocess, that the process is a
subprocess. The initial default value is no. The operating system displays the
message once every five minutes.
-password_grace_time days
Specifies the number of days a user has, after the password expiration time has
been exceeded, to change his or her password. During this grace time period, the
user must change his or her password the first time he or she attempts to log in.
Use this argument only when the value given in the argument
-password_exp_time is a nonzero value (since a 0 value in that argument
means that the system does not check whether passwords have expired). Note,
6-22
login_admin
this argument only applies to users registered with VOS passwords. The initial
default value is 0.
&<&/(!
-password_format password_format
Specifies the format in which a user must specify a new password. The allowed
values are any, which accepts a password in any format, and two_words, which
requires that a password consist of two words separated by a punctuation mark.
Note, this argument only applies to users registered with VOS passwords. The
initial default value is any.
&<&/(!
Specifies that a login process use as its process name the device name of the
terminal from which the process was started. The initial default value is no, which
means the value login is used instead of the terminal name.
Explanation
The login_admin command sets login parameters for a module for the current
bootload only. When the module is rebooted, the following parameters revert to their
initial default values:
Argument
Initial Default Value
max_logins
1023
-module
current_module
-password
Not set
-restrict
Not set
-unrestrict
Not set
-list_restricted
no
-delay_prelogins
yes
-password_exp_time
-min_password_len
-max_access_attempts
-max_bad_logins
no
-password_grace_time
-password_format
any
login
Command Overview
6-23
login_admin
Include the login_admin command in the module_start_up.cm file so that the

site-set values are maintained across bootloads. The values displayed by the display
form of the command are the values specified for the command in the
module_start_up.cm file or by a subsequent invocation of the login_admin
command.
The -password special_password argument permits the establishment of a
special session for which the users must use special_password as well as their
own passwords when logging in. The special session continues until you explicitly
remove the special-session password by setting it to the null string. (See the second
example later in this command description.)
A users account will be terminated if he or she:
exceeds the maximum number of consecutive login failures specified in the
-max_bad_logins argument
does not change his or her password for a period exceeding the combined number
of days specified in the -password_exp_time argument and the

-password_grace_time argument.
If a users account is terminated, use the set_registration_info command to
correct the record to allow the user to log in.
A value of 0 in the -max_bad_logins argument allows unlimited, consecutive
unsuccessful login attempts. A value of 0 in the -password_exp_time argument sets
no limit on the time a user can retain the same password. A value of 0 in the
-password_grace_time argument allows no extra time in which to change a
password; the users account is terminated when the password expiration time is
exceeded.
A users account is never terminated because of an expired password without the user
first being warned, unless the password expiration time is changed or the password
grace time is changed to a lower number of days. Changing either of these values to a
lower number may cause the time since a users last password change to already
exceed the combined limit imposed by these two values.
Therefore, before changing either of these values, perform the following steps.
1. Execute the update_password_info command to make sure that each user will
still have a currently valid password when the new expiration time is set.
2. Edit the notices file in the >system directory so that when users issue the
display_notices command, they will see a message telling them to change
their passwords immediately.
3. Use the broadcast command for a few days to send a message to all terminals
on a module that, unless users change their passwords before a specified time, the
passwords will expire.
6-24
login_admin
Command Overview
6-25
login_admin
In the following circumstances, operating system messages and prompts are issued
automatically to inform a user about password expiration and account termination.
If the time since a users last password change is within seven days of exceeding
the limit set in -password_exp_time, the user receives the message:

Your password will expire in N days
The user is then prompted for a new password. The user can either change the
password in response to the prompt or bypass the prompt by pressing the 5(7851!
key.
If the time since a users last password change has already exceeded the number
of days specified in -password_exp_time, but has not exceeded the combined

number of days specified in -password_exp_time and
-password_grace_time, that user receives the message:
Password expiration is imminent.
immediately.
Change your password
The user is then prompted for a new password. If the user attempts to bypass the
prompt by pressing the 5(7851! key, the warning message appears again. If the
user attempts to bypass the prompt a second time, the account is terminated.
If the users account has been terminated for exceeding the password expiration
and password grace times or for exceeding the maximum number of consecutive
unsuccessful login attempts, the user receives the message:
User account has been terminated
Examples
The following command establishes the password test as a special-session
password required for users to log in to the current module and prevents all users in
the group Sales from having access to the module.
login_admin
-password test
-restrict *.Sales
The following command removes the special-session password requirement for users
on the current module.
login_admin -password
The following command limits the number of users who can be logged in on module m6
to 30.
login_admin
6-26
30
-module m6
login_admin
The following command displays the restricted users list for module %wa#m4.
login_admin -module %wa#m4 -list_restricted
The restricted users are:
Install.*
*.ca
Pat_OBrien.*
Related Information
See Chapter 4, Registering Users, and the command set_registration_info.
Command Overview
6-27
logout_admin
logout_admin
Privileged
Purpose
The logout_admin command logs out inactive login processes after a specified
number of minutes.
Display Form
----------------------------- logout_admin ----------------------------current_module
-overseer_module:
-inactive_logout:
none
-dialup_grace_time: 15
-direct_grace_time: 120
Command Line Form

logout_admin -overseer_module module_name
-inactive_logout process_type
-dialup_grace_time minutes
-direct_grace_time minutes
Arguments
NOTE
the values set by the logout_admin command in the
module_start_up.cm file or by the most recent
invocation of the command.
-overseer_module module_name
The module whose inactive processes will be logged out. The initial default is the
current module.
6-28
logout_admin
-inactive_logout process_type
&<&/(!
Specifies the types of processes that will be logged out. The values are none,
dialup, and all. With the all value, processes running over both dialup and
direct lines will be logged out. The initial default value is none.
-dialup_grace_time minutes
Specifies the number of minutes that a process operating over a dialup line can be
inactive before the operating system logs it out. The initial default value is 15 and
the minimum value is 2. This argument has no effect unless all or dialup is
given for the -inactive_logout argument.
-direct_grace_time minutes
Specifies the number of minutes that a process operating over a direct line can be
inactive before the operating system logs it out. The initial default value is 120 and
the minimum value is 2. This argument has no effect unless all is given for the
-inactive_logout argument.
Explanation
This command enables inactivity logout. The values specified are in force for the
current bootload only. After a module reboot, the following parameters revert to their
initial default values:
Argument
-overseer_module
current_module
-inactive_logout
none
-dialup_grace_time
15
-direct_grace_time
120
To keep the values in force across bootloads, include a logout_admin command in

each modules module_start_up.cm file. Each time this command is executed,
VOS resets all four of the arguments. If you do not give a value for an argument, the
operating system uses the initial default value. If the value for -inactive_logout,
-dialup_grace_time, or -direct_grace_time has been set to a value other
than the default value, the operating system uses the current value.
When a process exceeds its grace time, the operating system issues a warning that the
process will be logged out in two minutes.
Command Overview
6-29
logout_admin
Examples
The following command causes any processes operating over a dialup line to be
logged out after it has been inactive for 22 minutes (20 minutes grace time, followed by
a warning message and another 2 minutes).
logout_admin
-inactive_logout dialup -dialup_grace_time 20
Related Information
See VOS System Administration: Configuring a System (R287) for information about
configuring devices and the dialup value.
6-30
6-
Purpose
The notify_security_violation command either starts or stops the notification
of security violations to a specified terminal. When notification is enabled for a terminal,
the operating system displays a message on that terminal whenever an entry is written
to the security_log.(date) file of a module.
Display Form
---------------------- notify_security_violation ----------------------terminal:
-module:
-off:
no
Command Line Form

notify_security_violation terminal
-module module_name
-off
Arguments
terminal
The name of the terminal to which notification is to be started or stopped. The
default value is the terminal of the current process. The name of the terminal must
be preceded by the pound sign (#).
If you do not give a value for this argument, notification to the terminal running the
current process stops when that process logs out. If you do give a value,
notification to the named terminal continues even after the current process logs
out, until notification is explicitly stopped with the -off argument.
-module module_name
The name of the module whose security violations are to be signaled, or are no
longer to be signaled, to the specified terminal. The default is the current module.
Command Overview
6-31
-off
&<&/(!
Disables notification to the specified terminal. The default is no, which enables
notification.
Explanation
Notification consists of a message displayed on the status line of the specified terminal
indicating that an entry was written to the file security_log.(date). The text of the
entry is not displayed.
A terminal receives notifications either until the process controlling that terminal is
logged out (if no value was given for the terminal argument) or until the terminal
named in the terminal argument is named in a subsequent
notify_security_violation command with the -off argument.
Examples
The following command stops notification of terminal term.12.2 of security violations
on the current module.
#term.12.2
Related Information
See Chapter 5, Managing Security.
6-32
-off
radius_admin
radius_admin
Privileged
Purpose
This command is used to configure, log out, or display the statistics of a VOS RADIUS
Server process.
Display Form
------------------------------- radius_admin----------------------------request: reconfigure
Command Line Form

radius_admin request
-module module_name
&<&/(!
request
Specifies what type of administrative request to perform. The possible values are
reconfigure, logout, or statistics. See the Explanation section following
for information on the values.
-module module_name
Specifies the module on which the request is to take place. The default value is the
current module.
Explanation
When the reconfigure value is specified, the VOS RADIUS server re-reads the
RADIUS configuration file. If any of the network configuration information changes for
either the primary or secondary server (such as IP address, socket number, or shared
secret), the VOS RADIUS Server denies all pending authentication requests. If the
network configuration has not changed, only the values for packet_timeout,
packet_retries, and multihosted are changed. It then switches to the new
configuration information and starts accepting new requests.
When the logout value is specified, the VOS RADIUS Server stops accepting new
requests, waits for existing requests to complete, and then terminates.
Command Overview
6-33
radius_admin
When the statistics value is specified, this command requests statistics from the VOS
RADIUS Server and displays them.
The following command requires write permission on the server queue:
6-34
radius_auth_server
radius_auth_server
Privileged
Purpose
This command accepts requests over a server queue and communicates with an
external RADIUS authentication service to authenticate a user name and password.
Display Form
---------------------------- radius_auth_server ----------------------------log: basic
-max_sockets: 10
-timeout:
60
-syserr:
no
Command Line Form

radius_auth_server
-log name
-max_sockets number
-timeout seconds
-syserr
Arguments
-log name
&<&/(!
Specifies the type of logging the command should perform. The possible values are
basic, major, detail, and debug. The basic name specifies messages that report
startup, shutdown, and administrative actions. The major name specifies messages
that include basic messages plus all denials of authentication requests. The detail
name specifies all major messages plus all acceptances and challenges of
authentication requests. The debug name is for use by Stratus Customer Assistance
Center (CAC) and Engineering personnel. The default is basic.
-max_sockets number
Specifies the maximum number of UDP sockets the command uses while processing
authentication requests. The number can range from 10 to 500. If more authentication
Command Overview
6-35
radius_auth_server
requests arrive than can be processed using the defined maximum number of sockets,
the messages will wait until sockets become available.
If the primary and secondary IP addresses are identical, each authentication request
requires the use of a single UDP socket. Otherwise, it requires the use of two UDP
sockets. The default is 10.
-max_timout seconds
Specifies the number of seconds the command waits for an authentication request to
complete (either by the external RADIUS authentication service or by the user who is
being challenged). The time can range from 1 to 600 seconds. Requests that take
longer than this time are denied. The default is 60 seconds.
&<&/(!
-syserr
Specifies that log messages should be written to the syserr_log.(date) in
addition to writing to terminal output. The default is to write messages to only the
terminal output.
Explanation
The radius_auth_server command is a VOS server process that accepts user
authentication requests over VOS server queues, passes them to an external RADIUS
authentication service, and replies to the request with the result obtained from the
external service.
You must run only one copy of this command at a time. You must run this command
on each module of a system that has users who are registered to require the use of
external authentication.
The radius_admin command can be used to force this command to re-read its
configuration file, and can be used to log out this command cleanly (between
authentication requests, instead of in the midst of processing requests, as it would if
the stop_process command was used).
If radius_auth_server is not running, no users who are registered to require
external authentication will be able to log in or use the FTP daemon. Stratus supports
two different FTP daemons. Only the STREAMS FTP daemon implements support for
users registered to use external authentication. The older OS TCP/IP FTP daemon
ignores this attribute.
This command is a part of VOS RADIUS Support (S268) and is present on a module
when this product is purchased. When VOS RADIUS Support is purchased, this
command is started up automatically by commands in module_start_up.cm. The
command may be restarted by a system administrator who has the proper access to
the configuration file and server queues.
6-36
radius_auth_server
This command relies on the STREAMS TCP product set; the IP address of the RADIUS
servers must be accessible via an Ethernet adapter that is configured to use a
STREAMS TCP driver. This command will not work if the only route to the external
RADIUS servers is via the OS TCP/IP product set.
Note that the radius_auth_server command requires read permissions to the
configuration file (master_disk)>system>queues>ext_auth>radius.table
and write permission to the server queues:
(master_disk)>system>queues>ext_auth>ext_auth.server_queue
Related Information
radius_admin
registration_admin
Command Overview
6-37
registration_admin
registration_admin
Privileged
Purpose
The registration_admin command is used to add users, delete users, change
information about users, or list registered users.
Display Form
-------------------------- registration_admin ------------------------action:
command_menu
-registration_database: path_name
-registration_table:
table_name
-broadcast:
yes
Command Line Form

registration_admin action
-registration_database path_name
-registration_tabletable_name
-no_broadcast
Arguments
action
&<&/(!
The action to perform on the registration and password databases. The allowed
values are command_menu, add_user, add_posix_ids, list_posix_ids,
update_user_info, delete_user, list_registered_users, and
process_table. The default value is command_menu. A brief description of
these actions follows.
command_menu
Displays a command menu from which you can select any of the following actions:
add_user, update_user_info, delete_user or
list_registered_users.
6-38
registration_admin
add_user
Displays the ADD NEW USER screens, which are used to add a new user to the
system.
add_posix_ids
Adds user IDs and group IDs for all existing users in the VOS registration database.
list_posix_ids
Displays a list of all registered user names and group names along with the
corresponding numeric user IDs and group IDs.
NOTES
1. Various functions in POSIX.1 require that POSIX IDs
be present in the user registration database.
2. You should invoke the registration_admin
command with the add_posix_ids value as soon
as the module is brought up, even if you are not
planning to run any POSIX applications. This is
necessary because certain applications shipped with
VOS are POSIX applications.
update_user_info
Displays the UPDATE USER INFO screens, which are used to modify information
about a user in the system. The second UPDATE USER INFO screen is the same
as the first ADD NEW USER screen.
delete_user
Displays the DELETE USER screen, which is used to delete a user from the system.
process_table
Batch-processes user information contained in the table file specified in
the -registration_table argument. Note that you cannot choose the
process_table action from the command menu. See the section Processing
Additions and Deletions as a Batch later in this command description for
information on registration tables.
These actions are described in more detail later in this command description.
When the action selected has completed successfully, the command menu is
redisplayed. Many different registration_admin actions can be made during
one execution of the registration_admin command.
Command Overview
6-39
registration_admin
-registration_database path_name
Specifies the database to be updated. The default is the target of the link
master_module>system>configuration>user_registration.sysdb
on the master module.
The master module is designated by the create_user_sysdbs command. The
registrations database is stored on the master module, and is broadcast to other
modules in the system when registration changes are made.
When a value is not entered for this argument, the registration_admin
command first looks for a link named master_password.sysdb in the >system
directory. If the link is missing, the operating system returns an error message.
-registration_table table_name
Specifies the table file to be processed. It contains information about users whose
records are to be added to or deleted from the registration tables. This argument is
meaningful only when the process_table action is selected.
If you select the process_table action and leave this value blank, the
registration_admin command looks for the file
master_module>system>configuration>registration_admin.table
and, if successful, processes that table. If unsuccessful, it returns an error
message.
&<&/(!
-no_broadcast
Suppresses the broadcast of the updated versions of the databases
user_registration.sysdb and change_password.sysdb to the directory
>system on all modules in the system. The default value is yes, which means the
files are broadcast.
Explanation
The registration_admin command updates the files
user_registration.sysdb and change_password.sysdb and displays
information about registered users. Use this command only if the registration
databases user_registration.sysdb and change_password.sysdb have
already been created. If they have not been created before the command is issued,
VOS displays an error message. See the create_user_sysdbs command if these
databases have not yet been created.
Before modifying the databases, VOS copies the registration and password databases
to user_registration.sysdb.backup and
change_password.sysdb.backup. If an error is encountered during execution of
registration_admin, VOS renames the databases being modified to
user_registration.sysdb.error and change_password.sysdb.error and
the backup databases are renamed user_registration.sysdb and
change_password.sysdb. This ensures that valid databases are always accessible
6-40
registration_admin
by the commands that open them, and that the databases in error are available for
examination.
NOTE
The registration databases are not updated until you have
exited the command.
The registration_admin command provides a menu of actions to select from, or
you can specify an action directly when you give the command. If you omit the action
argument or select the command_menu value, a menu is displayed.
Use the command menu to perform multiple actions. If you choose an action from the
command menu, VOS returns you to the menu when that action is completed, letting
you select another action to perform without reissuing the registration_admin
command.
Stratus recommends that you add both root and nobody as users and add root and
nobody as groups to the registration database. The user name root should be
registered in the group root, and the user name nobody should be registered in the
group nobody. This is necessary because some of the system processes may run as
root, and some applications may require the presence of the user name nobody.
Note, however, that the kernel disables login for both root and nobody.
Adding a New User

Add new users to the registration databases with the add_user action. The add_user
action provides screens for adding new user records one record at a time. To add many
users at the same time, consider issuing the process_table action, which
batch-processes a table file containing many user records. See the section
Processing Additions and Deletions as a Batch later in this command description for
details.
To add a new user with the add_user action, complete two screens with information
such as the users person name, password, group(s), and home directory. The Name
field, the Password field, and the first Groups field appear in inverse video, indicating
that a value is required in each of these fields.
If the home directory of the new user is to be the same as that users default home
directory (described later in this command description), VOS can create the home
directory, $, @, ~, [, ], {, }, \, |, -, ^, , :, /, , and + automatically and perform these related
activities:
set the users access and default access to the home directory
copy into it the standard abbreviations and start_up.cm files
create all appropriate links
Command Overview
6-41
registration_admin
To initiate automatic creation of the home directory, press the (17(5! key after
modifying both ADD NEW USER screens.
The ADD NEW USER screens follow.
NOTE
The key sequences that appear on your terminal are
dependent upon the type of terminal you are using.
REGISTRATION ADMIN
Name:
Alias:
Password:
ADD NEW USER
________________________________
________________________________
Groups:
Subsystems:
________________________________
________________________________
________________________________
_______________________
_______________________
_______________________
Home Dir:
________________________________________________________________
Language:
________________________________
ENTER
Continue
6-42
Shift-Funct 0
Display Menu
Shift-F7
Cancel Screen
registration_admin
REGISTRATION ADMIN
Privileged:
Default Privileged:
Password Type:
No Password Change:
Permanent Password:
Must Have Start Up Program:
Must Use Subsystem:
No Home Dir Change:
Priority:
Max Priority:
Max Processes:
Default Module:
ENTER
Register User
Create Home Dir
ADD NEW USER

no
no
VOS
no
no
no
no
no
0
0
0
________________________________
F15
Register User
Do Not Create
Home Dir
Shift-Funct 0
Display
Menu
Shift-F7
Cancel
Screen
Command Overview
6-43
registration_admin
Description of the Fields on the First Screen

Name
Required
The person name of this user, which must be unique to the system. Valid
characters for Name are numbers, upper- and lowercase letters, and a single
underline (_). The value in this field must have the form person_name, or simply,
name. The maximum length of Name is 32 characters. While a combination of
upper- and lowercase letters, as well as the special characters $, @, ~, [, ], {, },
\, |, -, ^, , :, /, , and + may be specified for the person name, the field itself is
case insensitive.
NOTE
If a user name or a portion of a user name is unique to a
system, the user can log in by entering the unique portion
of the user name. If Leslie Quincy is the only person
registered on the system with a Q in her name, she may
log in as Quincy, Leslie Q, or Q.
The Name value is also the name of the users default home directory in each of the
groups in which the user is registered. Note that you do not need to create a default
home directory in the group directory for each of the users groups. However, if the
user will be logging in to the default home directory, be sure that links exist from
group directories not containing the default home directory to the users actual
home directory. These links will not exist if you create the default home directory
manually or if you register the user in an additional group at a later date.
Alias
An alternate (and usually shorter) form of the value specified in the Name field. This
alias must be unique within the system and can be used in place of the person
name in the login command. The alias must be unique in the entire database; it
cannot match a person name or any other alias in the system.
Valid characters for Alias are numbers, upper- and lowercase letters, underlines
(_), and the special characters $, @, ~, [, ], {, }, \, |, -, ^, , :, /, , and +. The
maximum length of Alias is 32 characters. If you do not specify a value for Alias,
the user must use his or her full person name to log in.
Password
Required
The password that the user must supply each time he or she logs in. The user can
change the assigned password after login, unless the value in the No Password
Change field is yes. The length and format of the password are validated
according to the minimum length and format defined by the login_admin
command. You must insert a value in this field. To set further restrictions on
passwords, see the set_password_security command and Restricting
Passwords in Chapter 4.
6-44
registration_admin
NOTE
If the new password contains certain punctuation marks
that the operating system recognizes as delimiters (such
as !, (, ), , ;, or &), a user may not be able to log in by
giving the password on the command line form. A
password containing delimiters can be accepted if a user
issues it after VOS displays the Password? prompt.
Groups
Required
One or more groups in which the user is to be registered. The user must be
registered in at least one group. The group name, which must be unique within the
system, is case insensitive. Note, however, that the group name supplied at login
is case sensitive.
The first Groups field is required and is the users default group: if the user is
registered in more than one group and logs in without a group name, the operating
system automatically logs the user into the group named in the first Groups field.
Note that if you need to create a new group, you must first create a new group
directory.
Subsystems
The subsystems that the user is allowed to enter. Normally, a user enters a
subsystem with the -subsystem argument to the login command. However, if
the Must Use Subsystem value is yes, the operating system logs the user
directly into the subsystem named in the first Subsystems field.
For each subsystem named, the user must have a startup command macro that
will place him or her into that subsystem. The name of the command macro must
be subsystem_name_start_up.cm.
Home Dir
The path name of the users home directory. Enter a path name in this field to
specify a home directory other than the default home directory. Specify any of the
following:
a full path name
a path name containing the (master_disk) command function
a partial path name of the form >group_name>person_name
the null string
Specifying a full path name or a path name that contains (master_disk)

instructs registration_admin to insert the path name into the user registration
tables exactly as given. If you specify a partial path name, or if you do not enter a
value, registration_admin prompts you for the name of the default module.
Command Overview
6-45
registration_admin
From the module name, registration_admin creates a default home directory

using the default module, group name, and user name.
If the (master_disk) directory on the specified module (see the description of
Default Module) contains a link to a group directory on a disk other than the
master disk, the path name will apply to that group directory.
If the registration_admin command was able to create the default home
directory, it now performs the following additional activities:
sets modify access to the home directory and write default access to the
files it contains
copies the standard abbreviations and start_up.cm files from the
>system directory into the home directory

creates links from directories of other groups specified in the Groups field to
the home directory

creates links from other modules having directories with the same names as
the groups specified in the Groups field.

See Chapter 4, Registering Users, for more information on home directory
creation.
Language
The name of the language the user is registered to use by default. This value
determines which language-specific message files and date/time parameters the
users process uses. If this field is empty, the users process uses the systems
default language.
Description of the Fields on the Second Screen

Privileged
Permits the user to log in as privileged by giving the -privileged argument to
the login command. The default is no.
NOTE
When a user logs in as privileged, any processes the user
starts by invoking the batch or start_process
command are not privileged by default. See the
descriptions of the batch and start_process
commands in VOS Commands Reference Manual (R098)
for information on how to start privileged processes.
Default Privileged
Logs the user in as privileged unless he or she gives the -no_privileged
argument with the login command. The default is no.
6-46
registration_admin
This value must be no if the value in the Privileged field is no.

&<&/(!
Password Type
Determines which type of password authentication is required for the user. This
field has the following values: VOS and external. The default and value for all
users is VOS. When external is specified, it indicates that the user must be
authenticated using an external authentication service.
No Password Change
Restricts the user from changing a password with the login command. The
default is no.
Permanent Password
Prevents the users password from expiring. The password expiration time can be
set with the login_admin command. The default is no.
Must Have Start Up Program
Requires a start_up.cm file in the users home directory before the user can log
in. The default is no.
Must Use Subsystem
Limits the user to the subsystems named in the Subsystems fields. If the user logs
in without specifying a subsystem in the -subsystem argument of the login
command, the operating system automatically places his or her process in the
subsystem named in the first Subsystems field. The default is no.
No Home Dir Change
Restricts the user from specifying another home directory by using the login
commands -home_dir argument. The user may only use the default home
directory as a home directory. If the users registration record contains a home
directory path name, the operating system uses that value; otherwise, it creates the
default home directory path name from the users default module name, login
group name, and person name. If the user tries to give an unacceptable path name,
the operating system denies the user access. The default is no.
Priority
The priority that this users processes have by default. The range is from 0
through 9 (lowest through highest). For most users, assign priorities 3, 4, 5, or 6.
See VOS System Administration: Administering and Customizing a System (R281)
for information about the meaning of the priority levels. The default value is 0, the
lowest priority.
Max Priority
The maximum priority this user can request. The range is from 0 through 9 (lowest
through highest). The default value is 0, the lowest priority. Privileged users can
explicitly set a process to run at a higher priority level.
Command Overview
6-47
registration_admin
Max Processes
A value between 0 and 255 that represents the maximum number of processes,
excluding batch processes, that the user can create at one time on a module.
However, the actual number of processes that one user can create is 1023. A value
of 0 (the default) indicates that the user can create any number of processes.
Default Module
The name of a module. This value is used to create the default home directory path
name. Refer to the description of the Home Dir field for more information.
Updating a Users Registration Information

Selecting the update_user_info action displays the following screen.
NOTE
REGISTRATION ADMIN
UPDATE USER INFO
Name:
ENTER
Retrieve User
Records
Shift-Funct 0
Display
Menu
Shift-F7
Cancel
Screen
Type the users name and press (17(5! to access the first UPDATE USER INFO
screens. All the fields in the second UPDATE USER INFO screen are the same as the
fields in the first ADD NEW USER screensee the documentation for that screen earlier
in this section. The third UPDATE USER INFO screen has the same fields as the
second ADD NEW USER screen but includes two additional fields, Account Status
and Number Login Violations.
NOTE
6-48
registration_admin
REGISTRATION ADMIN
Privileged:
Default Privileged:
No Password Change:
Permanent Password:
Must Have Start Up Program:
Must Use Subsystem:
No Home Dir Change:
Priority:
Max Priority:
Max Processes:
Account Status:
UPDATE USER INFO

no
no
no
no
no
no
no
0
0
0
Terminated: no
Number Login Violations:
ENTER
Enter New Data
Shift-Funct 0
Display Menu
Shift-F7
Cancel Screen
Deleting a Users Registration Record

Delete user registration records from the registration databases with the
delete_user action. The delete_user action prompts for the name of the user.
Once you supply the name, VOS prompts to confirm the deletion of that users
registration record.
If you are deleting a large group of users, you may prefer to use the process_table
action, which batch-processes a table file containing records for many users. See
Processing Additions and Deletions as a Batch later in this command description for
details.
When you invoke the delete user action, the following screen appears.
NOTE
Command Overview
6-49
registration_admin
REGISTRATION ADMIN
DELETE USER RECORDS
Name:
ENTER
Delete User
Records
Shift-Funct 0
Display
Menu
Shift-F7
Cancel
Screen
After entering the users name and pressing the (17(5! key, the following prompt
appears.
Do you really wish to delete user_name?
(yes, no)
Type yes to delete the record and redisplay the command menu. Type no to cancel
record deletion and to redisplay the command menu.
After deleting a users registration record, delete the users home directory and all links
associated with that userthese activities are not handled automatically.
Processing Additions and Deletions as a Batch

The add_user and delete_user actions process user records one at a time. This
method is suitable to process a small number of records. To add and/or delete a large
number of user records, use the process_table action to process them all at one
time as a batch process. The process_table action cannot update user records in
batch. Records can only be updated one record at a time. See Updating the
Registration Database in Chapter 4 for instruction.
To use the process_table action, follow these steps.
1. Create the table input (registration_admin.tin) file that will contain the user
records to be added or deleted. Be sure this file resides in the directory
2. Edit the .tin file to add the data describing the user records to be added or
deleted. The record format for the registration_admin.tin file is stored in
(master_disk)>system>configuration>registration_admin.dd.
6-50
registration_admin
Here is the sample registration_admin.dd file:

/* This is the registration_admin file:
*/
/* "action" defines the kind of modification to be
performed */
/* on the registration databases: add (add_new_user)
*/
/*
delete (delete_user_records)*/
/* "person" is required for all actions
*/
/* "group1" is required for add
*/
/* "create_home_dir" is used for add only
*/
/* "default_module" is used for add only for creating
*/
/* the home dir when no home_dir value has been given
*/
organization: sequential;
index:
index:
person no_duplicates;
alias no_duplicates null_keys;
fields:
version
action
person
alias
password
group1
fixed bin (15) default (1),

char (32) var,
char (32),
/*required*/
char (32),
char (32) var,
char (32) var,
Command Overview
6-51
registration_admin
/*required-add*/
group2
char (32) var,
group3
char (32) var,
group4
char (32) var,
group5
char (32) var,
home_dir
char (256) var,
subsystem1
char (20) var,
subsystem2
char (20) var,
subsystem3
char (20) var,
language
char (32) var,
priv_classes
char (256) var,
privileged
bit (1),
default_privilegedbit (1),
no_password_changebit (1),
permanent_passwordbit (1),
must_have_start_upbit (1),
must_use_subsystembit (1),
no_home_dir_changebit (1),
register_for_usf bit (1),
create_home_dir
bit (1), /*add_new_user only*/
priority
fixed bin (15),
max_priority
fixed bin (15),
max_procs
fixed bin (15),
default_module
char (66) var,/*add_new_user
*/
end;
The action field is described in the instructions at the beginning of this file. Its
value can be either add or delete. The create_home_dir field is used to
specify whether the command creates the users home directory automatically, as
described previously in the Home Dir argument description. All other fields
correspond to fields on the ADD NEW USER form and are described earlier in this
section. When adding a user record, include all pertinent field values but when
deleting a user record only include the action and person values.
6-52
registration_admin
The following example illustrates a registration_admin.tin file.

/
=action
=person
=alias
=password
=group1
=group2
=subsystem1
=home_dir
=language
=privileged
=default_privileged
=create_home_dir
=priority
=max_priority
=max_procs
add
R_Smith
rs
tomato
Sales
Marketing
=action
=person
=alias
=password
=group1
=privileged
=default_privileged
=priority
=max_priority
=max_procs
add
T_Jones
tj
pepper
Sales
1
1
5
6
0
=action
=person
=privileged
=default_privileged
=priority
=max_priority
=max_procs
add
B_Adams
0
0
5
6
0
=action
=person
delete
K_Collins
=action
=person
delete
A_Barton
%s1#m6>Sales>Smith
us_english
1
1
1
5
6
0
Command Overview
6-53
registration_admin
3. Create the table file:

create_table
master_module>system>configuration>registration_admin.tin
Note that if you gave the registration_admin.tin file a different name and/or
location than documented, substitute the name you used and specify the name of
the data definition file registration_admin.dd with the create_table
commands -description_path argument.
4. Execute the registration_admin command with the process_table action.
If you created a .tin file with the recommended name and location, do not give
the -registration_table argument.
registration_admin process_table
If you used another name and/or location, give that name as the value of the
-registration_table argument.
registration_admin process_table -registration_table
table_name
The transactions have now been processed, and the user records have been
added to or deleted from the registration databases. Print the
registration_admin.tin file or copy it to another file to keep a record of the
users who were added or deleted. Delete or truncate the
registration_admin.tin file.

Give the command registration_admin list_registered_users or select
the List Registered Users item from the menu to display the LIST REGISTERED
USERS screen.
NOTE
6-54
registration_admin
REGISTRATION ADMIN
LIST REGISTERED USERS
USER NAME
GROUP (1)
Admin_Operator
Alice_Jones
Bob_Booth
Testers
Marketing
Sales
ENTER
Continue
Shift-Funct 0
Display Menu
Shift-F7
Cancel Screen
NOTE
If the registration database is large, it can take several
minutes for the list of registered users to appear on the
screen.
Related Information
See Chapter 4, Registering Users, and the create_user_sysdbs and
set_password_security commands.
Command Overview
6-55
security_admin
security_admin
Privileged
Purpose
The security_admin command enables or disables security logging on a module.
Display Form
-------------------------------- security_admin -------------------------------on
state:
Command Line Form

security_admin state
-module module_name
Arguments
state
&<&/(!
Enables security logging with the value. The default is on. Security logging is
disabled when the value is off.
-module module_name
The module on which the operating system is to stop or start security logging. The
default value is the current module.
Explanation
The security_admin command opens and logs access violation messages to the
file >system>security_log.(date). If security logging on a system has been
disabled, enabling event auditing with the audit_admin command will re-create a
security_log.(date) fileyou do not need to reissue the security_admin
command. Issuing audit_admin security -audit is logically equivalent to
issuing security_admin on.
6-56
security_admin
Examples
The following example disables security logging on module m9.
security_admin
off
-module m9
Related Information
See Chapter 5, Managing Security, and the description of the audit_admin
command for information about other messages that can be logged to the
syserr_log.(date) file.
Command Overview
6-57
set_object_audit
Privileged
set_object_audit
Purpose
The set_object_audit command selects system objects and internal commands to
be audited.
Display Form
--------------------------- set_object_audit ---------------------------pathname:
-internal_command:
state:
on
Command Line Form

set_object_audit
-pathname path_name
-internal_command internal_command
-state
Arguments
-pathname path_name
The path name of a file or device whose audit state is to be changed. Star names
are not accepted. Either this argument or the -internal_command argument
must be supplied. This argument and the -internal_command argument are
mutually exclusive.
-internal_command internal_command
Name of an internal command whose audit state is to be changed. Star names are
not accepted. Either this argument or the -pathname argument must be supplied.
This argument and the -pathname argument are mutually exclusive.
state
Enables/disables auditing for the designated object. The values are on and off.
The default value is on.
6-58
set_object_audit
Explanation
The set_object_audit command permits the selection of individual system objects
(files, directories, devices or internal commands) to be audited. The
set_object_audit command must be used in conjunction with audit_admin
object. It does not matter what order these commands are invoked. The audit
information is logged to the security_log.(date) file. In the following example, the
user sets object auditing on the salaries file. Messages to the
security_log.(date) file indicate that the file was opened (edited) and saved, and
that a backup of the file was created:
1:
95-06-01 16:06:20 EDT Watenabe.SysAdmin %tky#term.5.26

Event: OBJECT
Target: %tky#m5>Personnel>HQ>salaries
Text: Object audit changed from 0 to 1.
2:

Event: OBJECT
Text: Opened port 9, sequential file, for input.
3:

Event: OBJECT
4:

Event: OBJECT
Text: Renamed to salaries.backup.
A device name may be entered in the -pathname argument. However, it is not

possible to audit printers connected to VOS via the spooler facility. See Table 5-1 in
Chapter 5, Managing Security, for a list of operations related to object events that
can be audited.
Examples
The following command enables auditing on the file may_reports:
set_object_audit on -pathname %sal#m2>Reports>may_reports
Note that events related to the file are not audited until audit_admin object
-audit has been issued.
Command Overview
6-59
set_object_audit
The following command enables object auditing on the internal command

give_access:
set_object_audit on -internal_command give_access
Related Information
See Chapter 5, Managing Security, and the documentation for audit_admin,
configure_commands, and set_process_audit in this chapter.
6-60
6-
Purpose
The set_password_security command sets restrictions on the format of a
password.
Display Form
------------------------ set_password_security ------------------------m odule_name
module_name:
-forbid_vowels:
no
-forbid_repeating_chars:
no
-forbid_user_name:
no
-forbid_repeat_password:
no
-forbid_frequent_changes:
no
-num_hours_between_changes: 24
-forbid_passwords_in_table: no
-forbid_reverse:
no
-forbid_anagram:
no
-req_alpha_numeric:
no
-forbid_begin_end_numeric: no
-req_change_first_login:
no
Command Overview
6-61
Command Line Form

set_password_security module_name
-forbid_vowels
-forbid_repeating_chars
-forbid_user_name
-forbid_repeat_password
-forbid_frequent_changes
-num_hours_between_changes hours
-forbid_reverse
-forbid_anagram
-req_alpha_numeric
-forbid_begin_end_numeric
-req_change_first_login
Arguments
NOTE
the values set by the set_password_security
command in the module_start_up.cm file or by the
most recent invocation of the command.
module_name
Required
The name of the module on which the password restriction is to be set. The value
for module_name must be a single module. If you do not specify a value when you
first invoke the command, VOS prompts for the module name before displaying the
form of the command.
&<&/(!
-forbid_vowels
Prohibits passwords with vowels. If you omit this argument, a user may choose a
new password containing vowels. The initial default value is no.
&<&/(!
Prohibits passwords with repeating characters. If you omit this argument, a user
may choose a new password containing repeating characters. The initial default
value is no.
&<&/(!
-forbid_user_name
Prohibits a user from creating a password containing his name. User Tom_Jones
could not choose tom, jones, or tomjones as his password if this field is cycled
to yes. If you omit this argument, a user may choose a new password that is
contained in his user_name. The initial default value is no.
6-62
&<&/(!
Prohibits a user from selecting one of his last five passwords as the current
password. If you omit this argument, a user may choose a new password that is
the same as one of his previous five passwords. The initial default value is no.
&<&/(!
Prohibits a user from changing his password for a second time within the time
period defined by -num_hours_between_changes. If you omit this argument, a
user may change his password as many times as he chooses. The initial default
value is no.
-num_hours_between_changes hours
Specifies the number of hours a user must wait before changing his password
again. The minimum length of time is one hour. This argument has no effect unless
-forbid_frequent_changes is yes. The initial default value is 24.
&<&/(!
Prohibits a user from choosing a password that is contained in the file
(master_disk)>system>forbidden_passwords.table. A system
administrator may prohibit the use of certain passwords by including them in this
table. If you omit this argument, VOS ignores the forbidden_password.table
file, if one exists. The initial default value is no. See Restricting Passwords in
Chapter 4 for more information on using the forbidden_passwords.table file.
&<&/(!
-forbid_reverse
Prohibits a user from choosing a password that is the reverse of his user name. If
you omit this argument, a user may choose a password that is the reverse of his
user name. The initial default value is no.
&<&/(!
-forbid_anagram
Prohibits a user from choosing a password that is an anagram of his user name. If
you omit this argument, a user may choose a password that is an anagram of his
user name. The initial default value is no.
&<&/(!
-req_alpha_numeric
Requires the password to contain both letters and numbers. If you omit this
argument, a user may choose a password that does not contain both letters and
numbers. The initial default value is no.
&<&/(!
Prohibits a password that has a numeric character at the beginning or at the end.
If you omit this argument, a user may choose a password that begins or ends with
a numeric character. The initial default value is no.
&<&/(!
Requires a user to change his password after being registered as a new user by
registration_admin. (When the new user logs in via the login command for
Command Overview
6-63
the first time, he will automatically be prompted for a new password as if he had
typed login -change_password.) If you omit this argument, a new user is not
required to change his password when he first logs in. The initial default value is
no.
Explanation
The command set_password_security enables the restriction of passwords. This
command identifies the module to which the controls apply, the password formats that
will be permitted or required, the minimum number of hours between changes in
passwords, whether there are forbidden passwords specified in a table, and whether
the password must be changed the first time a user logs in.
When the set_password_security command is shipped, the default setting is to
have each control turned off. However, once you have set the arguments to provide the
desired level of security, the new values remain in effect until the module is rebooted.
To ensure that the correct security controls are in place each time the module is
rebooted, include the set_password_security command in the
module_start_up.cm file. The initial default values for the arguments of the
set_password_security command are as follows.
Argument
module_name
A value must be entered by the user
-forbid_vowels
no
no
-forbid_user_name
no
no
no
-num_hours_between_changes
24
no
-forbid_reverse
no
-forbid_anagram
no
-req_alpha_numeric
no
no
no
NOTE
All modules in a system must be running the same release
of the operating system and all must have the same
6-64
password security controls set. If this is not the case, a

user inherits the security controls of the module on which
his home directory resides. A user then cannot log into a
module that has lesser security controls and change his
password to one that would not be allowed on his home
module.
These restrictions only apply to users registered with
Password Type of VOS. They do not apply to users
registered with Password Type of external.
Examples
The following command sets password security controls for module m3 to prohibit any
part of the user name from being contained in the new password, forbid anagrams in
the new password, and forbid repeating characters in the new password.
set_password_security m3 -forbid_user_name -forbid_anagrams
The following command sets password security controls for all modules in the current
system to restrict the minimum number of hours between change to 200, and to require
alpha-numeric passwords.
set_password_security * -forbid_frequent_changes
-num_hours_between_changes 200 -require_alpha_numeric
Related Information
See Restricting Passwords in Chapter 4 of this manual.
Command Overview
6-65
set_priority
set_priority
Privileged
Purpose
The set_priority command sets the priority for one or more processes.
Display Form
----------------------------- set_priority ----------------------------priority:
process_name:
-user:
current_user
-module:
-ask:
no
Command Line Form

set_priority priority
process_name
-user user_name
-module module_name
-ask
Arguments
priority
Required
The priority level to be assigned to each designated process. The minimum priority
is 0, and the maximum priority is 9.
process_name
One or more processes that will receive the designated priority. A process_name
value can be a star name.
If you omit both process_name and -user, the operating system sets the priority
for the process issuing the command.
6-66
set_priority
-user user_name
One or more users whose processes will receive the designated priority. A
user_name value can be a star name. To give the name of another person, you
must be logged in as privileged. The default value is current_user.
-module module_name
The module that is running the processes whose priorities you are setting. The
default is current_module.
&<&/(!
-ask
Asks you if you want to set the priority for a process when you specify a star name
for process_name. The default value is no, meaning the operating system sets
the priority for each process without asking you.
Explanation
This command sets the priority for all processes that match the specified process name
and user name.
Unless you are logged in as privileged, you cannot:
change the priority of another users process
assign a higher priority to a process than the value specified in the registration
database entry of the user who owns the process. (This applies to all processes,
including your own.)
Examples
The following command sets a priority level of 7 for the process make_report.
set_priority
make_report
The following command sets a priority level of 5 for all processes of user Smith that
are running on module m3.
set_priority
-user Smith.*
-module m3
The following command sets a priority level of 6 on all process names with the suffix
.compute being executed by anyone in the accounting group on the current module.
set_priority
*.compute
-user *.accounting
Related Information
See VOS System Administration: Administering and Customizing a System (R281)
and the registration_admin command in this manual.
Command Overview
6-67
set_process_audit
set_process_audit
Privileged
Purpose
The set_process_audit command audits processes or users.
Display Form
-------------------------- set_process_audit --------------------------state: o n
process_name:
-user:
current_user
-module:
-ask:
yes
Command Line Form

set_process_audit
state
process_name
-user user_name
-module module_name
-no_ask
Arguments
state
Enables/disables process auditing for the designated process. The default is on.
See the Explanation section for operating system messages regarding verification
of process auditing.
process_name
The name or star name of a process or set of processes to be audited. The
command audits all of the processes whose names match process_name, except
for the process issuing the command. If process_name is a star name and you do
not specify -no_ask, the command prompts for confirmation to audit you. By
default, the operating system audits all processes identified by -user or -module.
6-68
set_process_audit
-user user_name
Specifies the name or star name of a user or set of users. This allows you to audit
only the processes named process_name that were started by the specified
users. By default, the operating system uses your user name. The command does
not audit the process from which you issue the command. Your process must be
privileged to audit another users process.
-module module_name
Specifies the module executing the processes to be audited. By default, the
operating system uses the module executing your login process.
&<&/(!
-no_ask
Suppresses the prompt, when you specify a star name for process_name, asking
whether to audit a process with a matching name. By default, the operating system
asks before auditing each process.
Explanation
This command audits a specified process. The audit_admin command must be
invoked in conjunction with this command in order for process auditing to log events to
the security log.
After invoking the set_process_audit command, VOS prompts you to verify which
processes to audit. If the value of the state argument is on, the system displays the
following message, asking you to verify the processes to be audited.
Verify processes to be audited.
If the value of the state argument is off, the system displays the following message,
asking you to verify the processes that are not to be audited.
Verify processes not to be audited.
Type yes to audit the process, no to cancel the audit, or info to get more information
about that specified process.
Examples
To audit all the activities of Emma Wilcox, invoke the following commands:
set_process_audit on -user Emma_Wilcox
Verify processes to be audited.
Emma_Wilcox.Education (login)? (yes, no, info) y
Enabling audit of Emma_Wilcox.Education (login).
audit_admin process -audit
Command Overview
6-69
set_process_audit
Related Information
See Chapter 5, Managing Security, and the documentation for the audit_admin
and the set_object_audit commands in this chapter.
6-70
6-
Purpose
This command changes the specified record in the change_password.sysdb file on
the master module and broadcasts the change to >system on all the other modules in
the system.
Display Form
------------------------- set_registration_info -----------------------user_name:
-password:
-module:
Command Line Form

set_registration_info user_name
-password password
-module module_name
Arguments
user_name
Required
The user whose record is to be changed in the password file on the master module.
The value given must contain the users person name as it is recorded in the
change_password.sysdb file. (This is the same value given in the registration
database.) If user_name includes a group name, the group name is ignored. The
operating system does not recognize an alias in this argument.
-password password
Required
Permits a users password to be modified by someone other than the user. The
password is not displayed on the screen. The length and format of the password
are validated according to the minimum length and format defined by the
login_admin command. Note that if the password is managed by an external
authentication service (such as RADIUS), it is not possible for a VOS System
Administrator or a VOS user to change their password. For information on
passwords, see Valid Passwords in Chapter 5.
Command Overview
6-71
-module module_name
The name of a module on another system. This argument is needed only to gain
access to the password database on another system.
Explanation
The set_registration_info command modifies the records of a specified user in
the registration database. When the -password argument is used, any password
changes that the user has made are nullified and a new password is created. The other
purpose is to reinstate the users account. Note that if the account you are reinstating
was terminated for reasons unrelated to passwords, you need to give only the
user_name argument.
This command is useful in several cases: when users have changed their passwords
and have forgotten them, when users are locked out of the system because their
passwords have expired, or when users accounts have been terminated because they
have exceeded the maximum allowable number of login attempts.
Examples
The following command changes the password of user Smith to jls on the current
module.
Smith
-password jls
Related Information
See Chapter 4, Registering Users, and the registration_admin and
create_user_sysdbs commands.
6-72
Privileged
Purpose
This command causes each registered user to have a currently valid password before
the password expiration time is set with the login_admin command.
Display Form
------------------------- update_password_info ------------------------No arguments required. Press ENTER to continue.
Command Line Form

Explanation
This command opens the change_password.sysdb database in the
>system>configuration directory on the systems master module and updates
each record by changing the time of the last password change to the time the command
is executed. The modified database is then broadcast over the system. This prevents
users from being denied login access because their passwords became out-of-date
when a new password expiration date was set.
Issue this command before using the login_admin command either to set a
password expiration time for the first time, or to change the current value to a shorter
time interval.
Related Information
See Chapter 4, Registering Users.
Command Overview
6-73
wait_for_overseer
wait_for_overseer
6-
Purpose
This is a system process command. It is used only within module_start_up.cm
files.
The wait_for_overseer command ensures that the Overseer process is running
before allowing module startup to proceed.
Display Form
-------------------------- wait_for_overseer --------------------------module:
Command Line Form

wait_for_overseer module_name
Arguments
module_name
The module containing the Overseer process. The default value is the current
module. Never give any other value for this argument.
Related Information
See VOS System Administration: Starting Up and Shutting Down a Module or
System (R282) and the overseer command in VOS System Administration:
Administering and Customizing a System (R281). See also the
module_start_up.cm file shipped with the installation software. This file is stored in
the directory (master_disk)>system>release_dir.
6-74
6-
Purpose
This is a system process command. It is used only within module_start_up.cm
files.
The wait_for_tp_overseer command ensures that the module startup waits only
the amount of time you specify before allowing the module startup to proceed. If the
TPOverseer takes longer to finish log processing, TP applications cannot be started
until log processing is completed.
Display Form
------------------------- wait_for_tp_overseer ------------------------time_out: 0
Command Line Form

wait_for_tp_overseer time_out minutes
Arguments
time_out minutes
A number, ranging from 0 to 30, specifying how many minutes the module startup
will wait for the TPOverseer to finish log processing before allowing the module
startup to continue. When the time_out value is not specified, the module startup
waits until the TPOverseer log processing is complete.
Related Information
See VOS System Administration: Starting Up and Shutting Down a Module or
System (R282) and the tp_overseer command in VOS System Administration:
Administering and Customizing a System (R281). See also the
module_start_up.cm file shipped with the installation software. This file is stored in
(master_disk)>system>release_dir.
Command Overview
6-75
6-76
Chapter 7
Subroutines
7-
This chapter documents the subroutines that are useful in writing programs for
RADIUS. The following subroutines are included:
For information on other subroutines, see the subroutine manuals.
Subroutines
7-1
Purpose
The s$get_registration_info subroutine returns registration information for a
specified user.
7-2
7-
Usage
char_varying (66)
char_varying (32)
short int
char_varying (256)
remote_module;
person_name;
error_code;
text;
/* Version 5 */
typedef struct $longmap
{
short int
short int
struct
{
long int
char
long int
long int
char_varying (32)
char_varying (32)
char_varying (256)
char_varying (32)
unsigned short
short int
short int
short int
char_varying (32)
char_varying (32)
short int
short int
short int
short int
char_varying (32)
short int
} data
long int
long int
} registration_info_v5_type;
version;
unused;
valid_password_expires;
priv_classes [4];
password_grace_time;
time_last_changed;
person;
password;
home_dir;
groups [5];
flags;
priority;
max_priority;
max_processes;
subsystem [3];
language;
min_password_len;
max_bad_logins;
num_login_violations;
password_format;
prev_passwords [5];
pad_bytes;
uid;
gids[5];
registration_info_v5_type info;
void s$get_registration_info ( char_varying (66) *,
char_varying (32) *,
registration_info_v5_type *,
short int *,
char_varying (256) *);
(Continued on next page)
Subroutines
7-3
(Continued)
s$get_registration_info (&remote_module,
&person_name,
&info,
&error_code,
&text);
Arguments
remote_module (input)
The name of the remote module you want to access. The value of
remote_module must be a full module name. If remote_module is the null string
(the string length of 0), the current module is used.
person_name (input)
The name or login alias of the person seeking access to the module. The value
cannot be a user starname.
info (input/output)
The structure that contains the registration information.
version (input)
The version number must be 5.
unused (output)
The value of this field is undefined.
valid_password_expires (output)
The date and time that the password of this user expires in operating system
integer date-time form. If the value is zero, the password never expires.
priv_classes (output)
This field is not presently used.
password_grace_time (output)
The number of seconds beyond the password expiration time that this user has
to log in and change his or her password.
person (output)
The name of the user.
password (output)
The encrypted VOS password of the user. This password must not be used if
the external_authentication flag is true, rather; the user must be
authenticated using the s$perform_ext_auththentication subroutine.
7-4
home_dir (output)
The full path name of the home directory of the user.
groups (output)
An array of VOS group names that the user is permitted to use.
flags (output)
The value of flags is a binary coding of logical variables that are described in
the following table. For information on how to decode the flags, see the
discussion of logical arguments in the VOS Subroutines manuals. All unused
switches are reserved for future use.
Bit
Switch Name
Description
16
external_authentication
If this switch is true, the user is registered for

external authentication and the caller must use
the s$perform_ext_authentication
subroutine.
32
must_change_password
If this switch is true, the user must change his or

her password at the next opportunity.
64
permanent_password
If this switch is true, the password never expires.
128
account_terminated
If this switch is true, the user is not permitted to

log in or use system resources.
256
obsolete0
This switch is not used.
512
no_home_dir_change
If this switch is true, the user is not allowed to

change his or her home directory to log in.
1024
obsolete1
This switch is not used.
2048
must_use_subsystem
If this switch is true, the user must specify a

subsystem that matches one of the values in the
subsystem array. If he or she does not, login will
use the first subsystem.
4096
must_have_start_up
If this switch is true, a user must have a

start_up.cm file in his or her home directory.
8192
no_password_change
If this switch is true, a user is not permitted to

change his or her password.
16384
default_privileged
If this switch is true, a process created for this

user is created as privileged unless the user
explicitly requests nonprivileged.
Subroutines
7-5
Bit
Switch Name
Description
32768
privileged
If this switch is true, a user is permitted to create

a privileged process.
priority (output)
The priority value of a process created for this user.
max_priority (output)
The maximum value of the priority of a process that is created for this user.
max_processes (output)
The maximum number of simultaneous processes that may be created for this
user.
subsystem (output)
An array that holds up to 3 names of subsystems that this user may specify at
login. The login command prefixes the name of the subsystem to the
start_up.cm macro. For example, a user with a subsystem of sales runs
sales_start_up.cm.
language (output)
The operating system language to use for a process created for this user.
min_password_len (output)
The minimum number of characters in a VOS password chosen by this user.
max_bad_logins (output)
If zero, this value is ignored. If greater than zero, the number of consecutive
logins that are rejected before the users account should be terminated.
num_login_violations (output)
The number of consecutive login attempts that have been rejected.
password_format (output)
The password format for this user. A value of 1 specifies any format. A value
of 2 specifies that this user must use a password that contains at least one
punctuation character and the first such punctuation character must not be the
first or last character.
prev_passwords (output)
An array that holds up to 5 of the most recently used passwords for this user.
This can be used to control the ability of the user to reuse old passwords.
pad_bytes (output)
The value of this field is undefined.
7-6
error_code (output)
A returned error code.
text (output)
Additional error information that is displayed when a nonzero error_code is
returned.
uid (output)
The POSIX uid (user ID) value for this user.
gids (output)
The POSIX gid (group ID) values that this user may use. These values are in the
same order as the group values.
Explanation
The s$get_registration_info subroutine get the VOS registration information for
a specified user.
Note that the returned password is enciphered using a one-way algorithm. To verify a
putative user-supplied password against their registered VOS password, you should
first encrypt the user-supplied password using the s$encipher_password
subroutine, and then compare the enciphered passwords. Stratus does not supply a
method to reverse an enciphered password.
The external_authentication flag indicates that the user must be authenticated
using an external authentication service. You must call the
s$perform_ext_authentication subroutine for this purpose.
The caller must have read permission on the following files:
(master_disk)>system>network_access.table
(master_disk)>system>change_password.sysdb
(master_disk)>system>master_password.sysdb
(master_disk)>system>user_registration.sysdb
The caller of s$get_registration_info must be privileged.
Examples
None
Related Information
s$encipher_password
s$verify_system_access
Subroutines
7-7
Purpose
This subroutine takes the information necessary to authenticate a user using an
external authentication service, communicates with the authentication service, and
returns the results to the caller.
7-8
7-
Usage
long int
short int
char_varying
char_varying
char_varying
long int
long int
long int
long int
char_varying
char_varying
short int
(128)
(32)
(128)
(128)
(128)
msg_type;
msg_priority;
client_handle;
person_name;
password;
chal_type;
auth_type;
timeout;
response;
cookie;
challenge;
code;
void s$perform_ext_authentication ( long int *,

short int *,
long int *,
long int *,
long int *,
long int *,
short int *);
s$perform_ext_authentication( &msg_type,
&msg_priority,
&client_handle,
&person_name,
&password,
&chal_type,
&auth_type,
&timeout,
&response,
&cookie,
&challenge,
&code);
Arguments
The symbolic names used in the following arguments are taken from the include file
ext_auth_message.incl.c, which is distributed with VOS RADIUS Support.
Subroutines
7-9
msg_type (input)
An integer that specifies whether this call is a new request for authentication, or a
response to a challenge from a previous request for authentication. It must have
one of the following values:
EAM_MSG_INITIAL
EAM_MSG_RESPONSE
1
2
When responding to a challenge, the client_handle, person_name, and

auth_type arguments must have the same value as in the initial message. The
msg_priority, chal_type, and timeout arguments may be different. The
password argument must contain the password that is applicable to the specified
challenge. The cookie argument requires special handling; see the information in
the cookie argument below.
msg_priority (input)
A nonnegative integer that specifies the priority of the authentication request
(relative to other authentication requests), and specifies whether the client wishes
to wait if no VOS external authentication server is presently available. The priorities
are in the range 0 (lowest) to 9 (highest). The default is to wait. If the subroutine
does not wait, the value 10 must be added to the priority.
client_handle (input)
A string that uniquely identifies distinct authentication requests originating from the
same client process. If a client never originates multiple distinct authentication
requests, it can set this argument to the null string or to a constant value. When this
argument is required, you may use the device or logical channel name. This value
appears, along with the process ID of the client, in the log messages generated by
the VOS RADIUS authentication server.
person_name (input)
The name to authenticate. This argument must have a non-null value.
password (input)
The password to authenticate. This argument may be null if no password is
required. When the auth_type argument has the value EAM_MSG_INITIAL, the
value for this argument is the initial password. When the auth_type argument
has the value EAM_MSG_RESPONSE, the value for this argument is the response to
the immediately previous challenge of this person_name.
chal_type (input)
An integer that specifies whether or not the client (caller) permits the user to be
challenged. It must have one of the following values:
EAM_CHAL_OK
EAM_CHAL_FORBID
7-10
1
2
The value 1 specifies that the client is prepared to handle single or multiple
challenges. The value 2 specifies that the client is not prepared to handle a
challenge. A user who is registered to require a challenge response and then
attempts to authenticate via a client that does not handle challenges will be denied
authentication.
auth_type (input)
An integer that specifies the type of authentication. It must have one of the
following values:
EAM_AUTH_LOGIN
EAM_AUTH_FTP
EAM_AUTH_RSN
EAM_AUTH_OTHER
1
2
3
4
The value 1 specifies that the client is the login command. The value 2 specifies
that the client is the FTP daemon. The value 3 specifies that the client is the remote
service network. The value 4 specifies that the client is some other, unspecified,
client.
timeout (input)
An integer that specifies the length of time, in units of 1/1024ths of a second, that
the subroutine should wait for the authentication request to complete. A value of
zero specifies no waiting. A value of -1 specifies an indefinite wait period. A
positive value specifies a specific wait period.
response (output)
An integer that specifies the response to the authentication request. It has one of
the following values:
EAR_RESPONSE_ACCEPTED
EAR_RESPONSE_DENIED
EAR_RESPONSE_CHALLENGED
1
2
3
A response of 1 or 2 is final. These values indicate, respectively, that the specified

combination of person, password, and other attributes has been authenticated or
has been denied authentication.
A response of 3 is conditional, and indicates that the authentication request needs
additional information before it can be granted. The client must display the text
contained in the challenge field to the user, must obtain a response, and must
submit a new authentication message containing this response. All of this must
happen within a time limit imposed by the external authentication service and a
similar time limit imposed by the VOS external authentication server.
Subroutines
7-11
cookie (input/output)
A character-string value used to coordinate between multiple invocations for the
same authentication request.
When the msg_type argument is 1 (initial authentication), this argument is ignored
on input, and is set on output as follows:
If a response code of 1 or 2 is returned, this argument is set to the null string.
If a response code of 3 is returned, indicating that the user has been
challenged, this argument is set to a non-null value.
When the msg_type argument is 2, the caller must pass the value that was
returned when the user was challenged (response code 3).
NOTE
The external authentication service can request multiple
challenges; therefore, even if you supply the correct
response to a challenge, another challenge could be sent.
The contents of this argument should not otherwise be used or modified by the
caller.
challenge (output)
A character-string value. If the response argument has the value 1 or 2, this
argument is null. Otherwise, it contains the text of the challenge. This text must be
displayed to the user.
code (output)
An integer, representing a standard VOS status code. All calls that successfully
invoke the external authentication service return zero. All nonzero values imply that
the authentication request was unsuccessful.
Explanation
The caller of this subroutine supplies the person name and password (if any) of the
person to authenticate. It also indicates whether it permits challenges, the type of
authentication request, a timeout value, and makes the call. This subroutine
communicates with the external authentication service and returns information
indicating whether or not the authentication request was accepted, denied, or
challenged.
A result that indicates acceptance or denial is final and no further action on the part of
the caller is required.
A result that indicates that the authentication request is being challenged requires the
caller display the text of the challenge to the user, obtain a response from the user, and
7-12
reinvoke the subroutine. The reinvocation must supply the same person_name,
client_handle, and auth_type as the initial call, must supply the response to the
challenge in the password argument, and must set the msg_type argument to 2
(EAM_MSG_RESPONSE). The value of the cookie argument must be the same as that
returned by the previous call with these arguments. The msg_priority, chal_type,
and timeout arguments may be different. For example, a client that can accept, at
most, a single challenge, can set chal_type to 1 on the initial call, and to 2 on the
subsequent call. Clients that can accept any number of challenges should set
chal_type to 1 on each call.
All calls that successfully invoke the external authentication service return a VOS
status code of zero. All calls that return a nonzero VOS status code have failed to
authenticate the user.
A caller that specifies that challenges are forbidden will never receive back a request
to perform a challenge; instead, any authentication attempts are denied. Note, these
attempts may succeed at the external authentication service, but the VOS external
authentication server will convert them to a denial.
A caller that does not wait a sufficiently long period of time for a response from the
external authentication service will receive a result that denies access to the user.
A caller that is asked to challenge the user, but which does not supply a correct
response within the time interval set by either the VOS or the external authentication
service (whichever one has the shortest time value), will receive a result that denies
access to the user.
A caller that supplies invalid argument values, or combinations of invalid values, will
receive a nonzero VOS status code value.
It is the responsibility of the client to insert any necessary real-time delays after a failed
login attempt to prevent an attacker from rapidly trying many different passwords.
Access Requirements
You need execute permissions on
>system>queues>ext_auth>ext_auth.server_queue in order to initiate an
authentication request.
You need execute permission on
>system>queues>ext_auth>ext_chal.1.server_queue to respond to a
challenge.
Subroutines
7-13
Error Codes
The following table explains some of the error codes this subroutine might return. Any
nonzero code indicates a failure of this subroutine to authenticate the user.
7-14
e$invalid_arg
An invalid argument was given. For example, one of the

integer arguments is out of range, or the person_name
argument is null.
e$invalid_msg_priority
The msg_priority argument is out of range.
e$invalid_message
An invalid response was received from the external

e$wrong_version
An invalid response was received from the external

Appendix A
VOS Commands for
Privileged Users
A-
This appendix lists the VOS commands for privileged users. If users are privileged,
they are able to use additional commands, requests, and subroutines besides those
available to general users. To be privileged, users must be registered with the
privileged attribute in the registration databases, or they must specify the
-privileged argument when they log in.
Table A-1. Privileged VOS Commands (Page 1 of 6)
Command
Documented In
accounting_admin
VOS System Administration: Administering and

Customizing a System (R281) and VOS System
Administration: Registration and Security (R283)
add_default_library_path

Customizing a System (R281)
add_disk
VOS System Administration: Disk and Tape

Administration (R284)
analyze_system
VOS System Analysis Manual (R073) and VOS System

Administration: Administering and Customizing a
System (R281)
audit_admin
VOS System Administration: Registration and

Security (R283)
batch_admin

batch_overseer

cancel_disk_retry

cancel_fast_disk_recovery

VOS Commands for Privileged Users
A-1

Command
Documented In
change_terminal
VOS System Administration: Configuring a

System (R287)
check_jiffy_times

configure_async_lines

System (R287)
configure_boards

System (R287)
configure_comm_protocol

System (R287)
configure_devices

System (R287)
configure_disks

Administration (R284) and VOS System Administration:
Configuring a System (R287)
configure_firmware_types

System (R287)
configure_languages

System (R287)
copy_dump

copy_kernel

create_os_symtab

delete_default_library_path

delete_disk

dismount_disk

display_bad_blocks

A-2

Command
Documented In
display_disk_label

display_calendar_clock

dump_disk

Administration (R284) and VOS System Administration:
Backing Up and Restoring Data (R285)
format_disk

initialize_boot_disk

initialize_disk

initialize_duplex_disk

iop_disk_tape_admin

link_boot_server

load_control_admin

load_kernel_program


Security (R283)
login
login_admin

Security (R283)
logout_admin

Security (R283)
memory_control

System (R287)
merge_dumps

A-3

Command
Documented In
mount_disk

network_watchdog

overseer

reconfigure_memory

System (R287)
recover_disk

refresh_disk

registration_admin

Security (R283)
reload_disk

remove_disk_pack

reset_configuration

System (R287)
salvage_disk

security_admin

Security (R283)
select_duplex_disk

set_bootload_time

set_date_time

set_default_library_paths

set_default_time_zone

A-4

Command
Documented In
set_jiffy_times

set_lock_wait_time

set_log_protected_file
set_object_audit

Security (R283)
set_partition_size


Security (R283)
set_priority
VOS Commands Reference Manual (R098), VOS

System Administration: Administering and Customizing a
System (R281), and VOS System Administration:
Registration and Security (R283)
set_process_audit

Security (R283)
set_tuning_parameters

setup_disk_pack

specify_cpu_configuration

System (R287)
spooler_admin
VOS System Administration: Administering the Spooler

Facility (R286)
start_disk_recovery

tp_overseer

uninitialize_disk

update_channel_info

System (R287)
A-5

Command
Documented In
update_default_cmd_limits

System (R287)
update_disk_label


Security (R283)
update_process_cmd_limits
validate_hub

The system administrator determines whether you can log in as privileged.

The set_priority command is privileged only if you are changing the priority of another users
process.
Many arguments of the spooler_admin command are privileged.
The update_process_cmd_limits command is privileged only if you are changing the process
limits of another users process.
A-6
Index
Index-
A
abbreviations file, 4-6
Access codes, 1-1, 1-3
device
null, 3-9
read, 3-9
write, 3-9
directory
modify, 3-6
null, 3-5
status, 3-6
undefined, 3-3, 3-5
file
execute, 3-3
null, 3-3
read, 3-3
write, 3-3
internal command
null, 3-13
read, 3-13
write, 3-13
Access control lists (ACLs), 1-3, 3-2
directory, 3-6
discretionary, 1-3
displaying for internal commands, 3-15
file, 3-3
in the installation software, 3-17
mandatory, 1-3
searching, 1-4
access event type, 5-7
Access lists
device, 3-9, 3-10
internal command, 3-13
sharing, 3-15
system_default, 6-9
Access rights, 1-1
determining, 1-4
displaying
device, 3-12
directory, 3-6
file, 3-3
enabling for internal commands, 6-9
giving, 2-2
device, 3-10, 3-11
directory, 3-7
file, 3-4
propagating through directories, 3-8
removing
device, 3-12
directory, 3-7
file, 3-5
undefined, 1-4
Access violations, 5-1
auditing, 5-7
displaying, 5-2
monitoring, 5-2, 6-55
notifying, 6-31
Accounting facility
disabling, 6-3
logging
commands, 6-3
file use, 6-3
port statistics, 6-3
transactions, 6-3
accounting_admin command, 6-2
ACLs. See Access control lists (ACLs)
ADD NEW USER screen, 6-38, 6-41, 6-43
Adding
disks, 2-5
home directories, 4-4
users, 4-4, 6-40
in a batch process, 6-49
screen for, 6-43
admin event type, 5-7
Administering
security logging, 6-55
system accounting, 6-2
system auditing, 5-6
Administrator commands, 6-1
Index-1
Index
Alias, 6-43
analyze_system command, 3-12
Associating
devices with device access lists, 3-9
drivers and modules with device access
lists, 3-10
internal commands with internal command
access lists, 3-15, 6-9
audit_admin command, 5-5, 6-5
Auditing
events
default, 5-6
selectable, 5-6
I/O events, 5-7
internal commands, 5-7, 6-9
enabling, 5-8
using the internal_commands.tin
file, 5-8
objects, 5-7
processes, 5-7, 6-67
system events, 1-1, 1-3
enabling, 6-6
users, 5-7
B
Batch processes and registration, 6-49
Broadcasting registration databases, 6-39,
6-72
C
C2 security standard, 1-1
Case sensitivity
password, 4-10
user names in registration tables, 6-43
change_password.sysdb file, 3-17, 4-2,
6-70, 6-72
Changing
module name, 4-12
passwords, 4-8, 6-46
minimum hours between, 6-61
system name, 4-12
Characters in user names, 1-2
Command access lists. See Internal commands
access lists
Commands, 6-1
accounting_admin, 6-2
audit_admin, 6-5
configure_commands, 6-9
Index-2
create_user_sysdbs, 4-1, 6-12

display_registration_info, 6-14
log_registered_users, 4-11, 6-17
logging, 6-3
login_admin, 5-13, 6-19
logout_admin, 6-27
notify_security_violation, 5-2,
6-30
radius_admin, 6-32
radius_auth_server, 6-34
registration_admin, 6-37
security_admin, 5-2, 6-55
set_object_audit, 6-57
set_password_security, 5-13, 6-60
set_priority, 6-65
set_process_audit, 6-67
set_registration_info, 6-70
update_password_info, 6-72
VOS internal, 3-13
wait_for_overseer, 6-73
wait_for_tp_overseer, 6-74
configuration event type, 5-7
configure_commands command, 3-15, 6-9
Copying access rights throughout
subdirectories, 3-8
create_user_sysdbs command, 4-1, 6-12,
6-39
Creating
group directories, 2-2
links for the password database, 4-1
registration_file.tin file, 6-17,
6-53
tables
devices, 3-10, 3-11
forbidden_passwords, 4-11
user registration records, 4-8
user-defined log records, 6-3
D
DACLs. See Default access control lists
(DACLs)
Data definition files
forbidden_passwords.dd, 4-10
internal_commands.dd, 3-14
registration_admin.dd, 6-50
Databases for registration, 4-1, 6-39
Index
Default access control lists (DACLs), 1-4, 3-2

access violations, 5-1
displaying, 3-8
Default access rights
determining, 1-4
displaying, 3-8
removing, 3-8
Default directory, 6-40
Default events, 5-6, 5-7
Default groups, 6-44
DELETE USER screen, 6-38
Deleting
group directories, 2-7
users, 4-7, 6-48
Determining
user access to objects, 1-4
VOS internal commands, 3-13
Devices
access lists, 1-3, 3-9, 3-10
creation of, 3-9, 3-10
determining, 3-12
giving access to, 3-10, 3-11
removing access from, 3-12
tape drive, 3-9
access rights, 3-9
displaying access to, 3-11
devices.table file, 3-10, 3-11
devices.tin file, 3-10, 3-11
Directories
access rights, 3-5
ACLs, 3-6
giving access to, 3-7
group, 1-2
creating, 2-2
deleting, 2-7
full path name of, 2-1
linking to the(master_disk)
directory, 2-2
moving, 2-6
home, 4-4, 6-40, 6-44
(master_disk), 2-1
principal home, 4-4
propagating access through, 3-8
removing access from, 3-7, 3-8
>system>acl, 3-9, 3-10
top, 2-1
Disabling
accounting facility, 6-3
event auditing, 6-6
internal command access settings, 3-16
Disks, 2-5
command, 6-14
Displaying
access violations, 5-2, 6-31
ACLs
device, 3-12
directory, 3-6
file, 3-3
audited event types, 6-6
DACLs
of files in a directory, 3-7
of files in the acl directory, 3-12, 3-16
default access rights, 3-8
subprocess information, 6-22
Displaying access to devices, 3-11
Drivers and modules
setting access to, 3-10
dump_dvt request, 3-12
E
Enabling
auditing
event, 5-5
object, 6-57
objects and internal commands, 5-7
processes and users, 5-7
file, 4-11
security log, 6-55
Entries in access lists, 3-2
Events, 1-1, 1-3
auditing, 6-5, 6-6
default, 5-6, 5-7
information logged, 5-8
selectable, 5-6, 5-7
types
displaying audited, 6-6
types of, 5-7, 6-5
execute access, 3-3, 3-13
Index-3
Index
F
Files
abbreviations, 4-6
access rights, 3-3
default, 3-2
change_password.sysdb, 3-17, 4-2
devices.tin, 3-10, 3-11
displaying DACLs of, 3-7
giving access to, 3-4
internal_commands.table, 6-9
logging, 6-3
master_password.sysdb, 4-2, 6-39
module_start_up.cm, 5-13
network_access.table, 5-2
radius.dd, 5-16
radius.tin, 5-16
registration_file.tin, 4-7, 6-52
security_log.(date), 5-1, 6-30
start_up.cm, 4-6
syserr_log.(date), 6-55
system_default, 1-3
user_registration.sysdb, 3-17,
6-39
forbidden_passwords.dd file, 4-10
forbidden_passwords.table file, 4-2,
4-11
forbidden_passwords.tin
case sensitivity in, 4-10
FTP access, 5-11
unauthorized, 5-11
ftpd daemon
-allow_any_port, 5-11
-security_check_file, 5-11
Full path name of a group directory, 2-1
G
Giving access
default, 3-8
device, 3-10, 3-11
directory, 3-7
file, 3-4
Group directories, 1-2
creating, 2-2
deleting, 2-7
linking to the (master_disk)
directory, 2-2
links, 2-5
location on master disk, 2-1
Index-4
moving, 2-6
planning structure of, 2-1
Groups, 1-2, 6-44
in installation software, 2-8
names, 1-2
number a user may belong to, 2-1
representing all a user is in, 1-3
representing all users in a, 1-3
setting device access lists for, 3-10
SysAdmin, 2-8
System, 2-8
unknown, 3-6
H
Home directory, 4-4, 6-40, 6-44
files in, 4-6
linking to others in the same group, 2-5
I
I/O traffic statistics, 6-3
Identifiers. See Names
Inactive processes logged out, 6-27
Installation software, 3-17
groups in, 2-8
Internal commands
access lists, 1-3, 3-13
removing access from, 3-16
access rights, 3-13
auditing, 5-7
displaying access to, 3-15
listing, 3-13
restricting access to, 3-13
setting access to, 3-13, 6-9
internal_commands.dd file, 3-14
internal_commands.table file, 6-9
internal_commands.tin file, 3-14
internal command auditing, 5-8
setting internal command auditing in, 5-8
io event type, 5-7
L
Limiting maximum users on a module, 5-13
Linking
between the home directories and group
directories, 2-5
Index
group directories to the

(master_disk), 2-2
to the registration database, 4-1
LIST REGISTERED USERS screen, 6-53
Listing
audited event types, 6-6
internal commands, 3-13
users
registered, 4-9
restricted, 6-21
log_registered_users command, 4-11,
6-17
Logging
event information, 5-8
statistics, 6-2
user-defined logs, 6-3
Logging in
to subsystems, 6-44
to the operating system, 4-1
attempts, 6-22
Logical disk volume capacity increases, 2-6
login_admin command, 5-13, 6-19
special-session password, 5-14
logout_admin command, 5-14, 6-27
M
Managing security, 4-1
Mandatory ACLs, 1-3
Master module, 4-1
specifying, 6-12
(master_disk) directory, 2-1
master_password.sysdb file, 4-2, 6-39
Maximum users, 5-13
Menus for registration functions, 6-40
Messages
security_log.(date), 5-3
syserr_log.(date), 5-8
modify access, 3-6
Modifying
change_password.sysdb file, 6-70
module_start_up.cm file, 5-13
audit_admin command, 6-6
configure_commands command, 6-10
login_admin command, 6-23
logout_admin command, 6-28
command, 6-63
wait_for_overseer command, 6-73
command, 6-74
Modules
changing the name of, 4-12
default, 6-47
setting password restrictions on, 6-61
statistics for, 6-2
Monitoring
access violations, 5-2, 6-55
command use, 6-3
file use, 6-3
port use, 6-3
process statistics, 6-3
transaction processing, 6-3
Moving group directories, 2-6
must_have_start_up_program
attribute, 4-4
N
Names
group, 1-2, 6-44
person, 1-2
defining, 6-43
star, 1-3
user, 1-2
aliases, 6-43
network_access.table file, 5-2
command, 5-2, 6-30
null access, 1-4, 3-3, 3-5, 3-9, 3-13
O
object event types, 5-7
Objects, 1-1
access rights for, 3-1
auditing, 5-7, 6-57
discretionary access control lists for, 1-3
Operating system logins, 4-1
Overseer process, 2-8
P
Password database, 6-13
Passwords, 3-17, 4-2, 5-21, 6-44
access violations, 5-1
case sensitive, 4-10
change_password.sysdb file, 4-9
changing, 1-5, 4-8, 6-46
Index-5
Index
expiration of, 6-21

forbidden_passwords.table file, 4-2
creating, 4-11
minimum length of, 6-22
parameters for, 6-19
requiring
both letters and numbers, 6-62
minimum hours between
changes, 6-61
new password after first log in, 6-62
restricting, 4-9, 6-60
creation of, 5-13
frequent changes of, 6-61
repeated passwords, 6-61
repeating characters, 6-61
specific, 4-11, 6-62
user names, 6-61
vowels, 6-61
special session with login_admin, 5-14
updating, 6-72
validating, 4-2
Person names, 1-2
defining, 6-43
Planning group directory structure, 2-1
Port accounting, 6-3
Pre-login process, 6-21
Preregistered users, 1-5
Principal home directory, 4-4
Priority levels, 6-46
maximum, 6-46
specifying, 6-65
Privileged commands
accounting_admin, 6-2
registration_admin, 6-37
set_password_security, 6-60
set_priority, 6-65
set_registration_info, 6-70
update_password_info, 6-72
Privileged processes, 3-17, 6-45, 6-66
Process control
stopping processes, 6-67
>process_dir_dir directory, 5-15
process event type, 5-7
process_table action, 6-49
registration_admin command, 4-8
Processes
auditing, 5-7, 6-67
batch, 6-49
logging out inactive, 6-27
Index-6
pre-login, 6-21
priority level of
specifying, 6-65
privileged, 6-45
service, 6-1
statistic logging of, 6-3
subprocess, 6-22
propagate_access command, 3-8
R
RADIUS
access-request packets, 5-30
FTP Daemon error messages, 5-4
login command error messages, 5-4
reject authentication requests, 5-31
shared secret, 5-20
test procedure, 5-25
radius_admin command, 6-32
radius_auth_server command, 6-34
radius.tin file, 5-17
read access, 3-3, 3-9, 3-13
Registered users list, 6-53
Registering users, 4-1, 4-2, 4-4, 6-37, 6-40
batch processing, 6-40
Registration databases, 3-17, 4-1, 6-13, 6-39
broadcasting, 6-39
master, 4-1
optional files, 4-2
specifying, 6-39
system, 4-1
Registration information, 4-8
deleting, 6-48
updating, 4-8
registration_admin command, 6-37
invoking after adding a new group
directory, 2-3
menus for, 6-40
process_table action, 4-8, 6-49
registration_admin.dd file, 6-50
registration_file.tin file, 4-7, 6-17,
6-52
Removing access
default, 3-8
device, 3-12
directory, 3-7
file, 3-5
Index
Restricting
access
device, 3-10, 3-11
directory, 3-7
file, 3-4
number of users on a module, 6-20
passwords, 4-9, 5-13, 6-60
users, 5-14, 6-21
listed, 6-21
Restricting access
STREAMS driver or module, 3-11
RFC 2138, 5-21, 5-30
S
s$get_registration_info, 7-2
s$perform_ext_authentication, 7-8
Searching
ACLs, 1-4
DACLs, 1-4
Security
government standards, 1-1
logs, 4-9, 6-55
managing, 4-1
overview of, 1-1
violations
auditing, 5-7
notifying, 6-30
security event type, 5-7
security_admin command, 5-2, 6-55, 6-55
security_log.(date) file, 5-1, 6-30
messages, 5-3
Selectable events, 5-6, 5-7
Service processes, 6-1
set_object_audit command, 5-7, 6-57
set_password_security command, 4-9,
4-11, 5-13, 6-60
set_priority command, 6-65
set_process_audit command, 5-7, 6-67
set_registration_info command, 6-70
Sharing access lists, 3-15
Special sessions, 6-20
Specifying
master module, 6-12
password expiration, 6-21
priority levels, 6-65
process priority, 6-65
registration databases, 6-39

registration tables, 6-39
Star names
in user names, 1-3
representing all members of a group, 1-3
start_up.cm file, 4-6, 6-46
subsystem, 6-44
Starting security logging, 6-55
Statistics, 6-2
command use, 6-3
file use, 6-3
monitoring process, 6-3
port use, 6-3
transaction processing, 6-3
status access, 3-6
Stopping security logging, 6-55
STREAMS drivers and modules
setting access to, 3-10
Subprocesses, 6-22
Subroutines
s$get_registration_info, 7-2
s$perform_ext_authentication,
7-8
Subsystems, 6-44, 6-46
SysAdmin group, 2-8
access for, 2-8, 3-17
syserr event type, 5-7
syserr_log.(date) file, 6-55
>system>acl directory, 3-9, 3-10
System events, 1-1
auditing, 1-3, 5-5
System group, 2-8
System objects, 1-1
System process commands, 6-1
wait_for_overseer, 6-73
wait_for_tp_overseer, 6-74
system_default access list, 6-9
system_default file, 1-3
Systems
changing name of, 4-12
registration databases for, 4-1, 4-2
setting password restrictions on, 6-61
Index-7
Index
Tape drive device access list, 3-9

Terminating user accounts, 6-22
Top directory, 2-1
Transaction logging, 6-3
Transaction processing, 6-74
Valid characters in user names, 1-2

Validating user names and passwords, 4-2
Volumes, 2-6
VOS
abbreviations, 4-6
determining access rights, 1-4
VOS RADIUS authentication server
messages
-basic, 5-22
-detail, 5-25
-major, 5-24
VOS RADIUS Service
registration, 5-21
VOS RADIUS Support, 5-15
module_start_up.cm, 5-20
queues, 5-20
U
Undefined access, 1-4
undefined access, 3-3, 3-5
Unique user names, 6-43
Unknown group access, 3-6
UPDATE USER INFO screen, 6-38
update_password_info command, 6-72
Updating
password information, 6-72
registration database
changing a module name, 4-12
changing a system name, 4-12
user registration information, 4-8
user_registration.sysdb file, 3-17, 6-39
Users, 1-3
access rights to objects, 3-1
adding, 4-4, 6-40
screen for, 6-43
auditing, 5-7
changing passwords of, 4-8, 6-46, 6-70
deleting, 4-7, 6-48
determining access for, 1-4
groups, 1-2
limitations on group membership, 2-1
listing registered, 4-9, 6-17, 6-53
maximum on a module, 5-13
names of, 1-2, 5-21
aliases, 6-43
star names in, 1-3
validating, 4-2
preregistered, 1-5
registering, 4-1, 6-37
records of, 4-8
representing all groups of, 1-3
representing all members in a group, 1-3
representing all registered, 1-3
restricting, 6-21
maximum login attempts for, 6-22
total number on a module, 6-20
Index-8
W
wait_for_overseer command, 6-73
wait_for_tp_overseer command, 6-74
write access, 3-3, 3-9, 3-13

Security (R283)
Customer Survey
We value your comments...

Our goal is to continuously improve the quality of our documentation. You can help us achieve this goal by
taking a few minutes to complete this survey.
Please rate the quality of this manual in each of the following areas.
Strongly
Agree
Agree
Neutral
Disagree
Strongly
Disagree
Technical Accuracy
The product works as described in the manual.
Completeness
The information is complete.
Clarity
The information is easy to understand.
Fold
Organization
The information is easy to find.
Figures
The figures are clear and useful.
Cut along dotted line.
Examples
The examples are clear and useful.
Index
The topics lead to the information that you need.
Physical Appearance
The format of the manual enhances readability.
Effectiveness
The manual helped you to perform your job.
What did you like most about this manual? _____________________________________________________

_______________________________________________________________________________________
What did you like least about this manual?_____________________________________________________

_______________________________________________________________________________________
Fold
Is there any information that you would like to have added to this manual? If so, where would it be most helpful?
New information that you would like to have added
Location
____________________________________________________
___________________
____________________________________________________
___________________
Would you like to see more examples in this manual? If so, where would they be most helpful?
New examples that you would like to have added
Location
____________________________________________________
___________________
____________________________________________________
___________________
Did you find errors in this manual? If so, please note the problem(s) and the location in the manual.
Any inaccuracies that you found in this manual
Location (page/paragraph)
____________________________________________________
___________________
____________________________________________________
___________________
Customer Survey
R283-04
7
Do you have any other comments or suggestions? ___________________________________________________

___________________________________________________________________________________________
Would you please complete the following information so that we may better understand who reads our manuals?
Name: ____________________
Title: ____________________
Company: _________________________
Mailing Address: ____________________________________________________________________________

What is your level of expertise with this product? ____________________________________________________
What tasks do you perform using this product? _____________________________________________________
Would you be willing to talk to us about your comments?
Yes
No
If yes, what is your phone number and when is a good time to call you? ___________________________________
Fold
Thank you for your help
BUSINESS REPLY MAIL

FIRST-CLASS MAIL
PERMIT NO. 3
MAYNARD, MA
POSTAG E WI LL B E PAID BY ADD RESSEE
Stratus Technologies, Inc.

c/o Publications Manager
111 Powdermill Road
Maynard, MA 01754-9948
Cut along dotted line.
NO POSTAGE
NECESSARY
IF MAILED
IN THE
UNITED STATES
Fold
111 Powdermill Road

Maynard, MA 01754-3409
R

VOS Registration and Security r283-04

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VOS Registration and Security r283-04

Uploaded by

Copyright:

Available Formats

VOS System Administration:

Registration and Security

The information contained in this document is subject to change without notice.

1. Overview of Access Control and Security on VOS Modules

2. Managing Group Directories

3. Controlling Access to System Objects

VOS System Administration: Registration and Security (R283)

Appendix A. VOS Commands for Privileged Users

VOS System Administration: Registration and Security (R283)

Registration Databases on a Three-Module System

File Access Rights

VOS System Administration: Registration and Security (R283)

Every module must have a copy of the module_start_up.cm file.

VOS System Administration: Registration and Security (R283)

commands, subroutines, code fragments, and names of files and directories).

Key Mappings for VOS Functions

VOS System Administration: Registration and Security (R283)

Format for Commands and Requests

Command Line Form

Explains briefly what the command or request does.

The default value is the current user, module, system, or

VOS System Administration: Registration and Security (R283)

The Notation Used in Command-Line Forms

Required argument for which you can specify multiple values.

Set of arguments that are mutually exclusive; you must specify

Optional argument for which you can specify multiple values.

Set of optional arguments that are mutually exclusive; you can

There are predefined values for this argument. In the display

You cannot issue the command or request without specifying a

Only a privileged process can specify a value for this argument.

description: Explanation, Error Messages, Examples, and Related Information.

including updates and corrections to Stratus manuals and a glossary of terms.

Stratus. It enables Stratus customers to view, search, download, print, and

maint_request command at the system prompt. Complete the on-screen form

VOS System Administration: Registration and Security (R283)

Commenting on This Manual

Type comment_on_manual followed by -form, then press (QWHU! or 5HWXUQ!. Enter

VOS System Administration: Registration and Security (R283)

Access Control and Security Concepts

Overview of Access Control and Security on VOS Modules

Access Control and Security Concepts

VOS System Administration: Registration and Security (R283)

Access Control and Security Concepts

User Star Names

the groups in which he or she is registered. The user star name

name *.* represents all registered users.

Access Codes and Access Lists

System Events and Auditing

Overview of Access Control and Security on VOS Modules

How VOS Determines User Access

How VOS Determines User Access

VOS System Administration: Registration and Security (R283)

Overview of Access Control and Security on VOS Modules

VOS System Administration: Registration and Security (R283)

This chapter documents how to manage group directories. Sections include:

Groups and Group Directories

Planning the Group Directory Structure

Groups and Group Directories

Creating the Initial Group Directories

VOS System Administration: Registration and Security (R283)

Groups and Group Directories

Adding a Group Directory

Groups and Group Directories

Storing Large Group Home Directories on Multiple Disks

Type comment_on_manual followed by -form, then press (QWHU! or 5HWXUQ!. Enter

name . represents all registered users.