Document revision date: 19 July 1999

If each user has a unique UIC, you can use the Backup utility (BACKUP) to remove the user's files, even if the files are scattered throughout the directory structure. See the Backup utility section in the OpenVMS System Management Utilities Reference Manual for more information.

Examples

1. The following example of a BACKUP command is used to remove files:

   $ BACKUP/DELETE PUBLIC:[...]/BY_OWNER=[21,103] MTA0:PUBLICUIC.SAV

   
   This BACKUP command copies and deletes only those files owned by the specified UIC on disk PUBLIC. The files are copied into a save set named PUBLICUIC.SAV on device MTA0. Note that the BACKUP/DELETE command does not delete the directory files (file type .DIR) for the account.

2. To recover lost files, enter the ANALYZE/DISK_STRUCTURE command in the following format:

   ANALYZE/DISK_STRUCTURE/REPAIR/CONFIRM device-name:

   
   See Section 8.12.3 for a complete description of how to recover lost files. See the OpenVMS System Management Utilities Reference Manual for information on using the Analyze/Disk_Structure utility.

To disable an account without deleting it, set the disable user flag (/FLAGS=DISUSER) using AUTHORIZE. If the user is logged in, the account is disabled only after the user logs out.

6.8 Restricting the Use of Accounts

Workload schedules often dictate the days and times your system is used to perform specific operations. Depending on the nature of the work performed at your site, you might want to control when certain users are allowed to log in. Use the Authorize utility (AUTHORIZE) to place controls in the login characteristics fields of the UAF record to restrict the days and times a user can log in and to inhibit certain login functions.

The following sections describe how to perform these tasks:

Task	Section
Setting day types	Section 6.8.1
Restricting logins to specific times	Section 6.8.2
Restricting login functions	Section 6.8.3
Using login command procedures for restricted or captive accounts	Section 6.8.4
Setting priorities for user processes	Section 6.8.5

For a detailed description of the qualifiers used to restrict the use of accounts, see the Authorize utility section in the OpenVMS System Management Utilities Reference Manual.

6.8.1 Setting Day Types

You can restrict the use of certain accounts by defining the days of the week as either PRIMARY or SECONDARY, and then assigning login restrictions to these day types. For example, if you define the days Saturday and Sunday as SECONDARY days, then any restrictions you assign to the SECONDARY day type apply to both.

You can assign two types of login restrictions to either day type:

Restriction	Description
Time restrictions	Limits logins to specific hours of the day
Function restrictions	Limit types of login

The default user record defines the five weekdays (Monday through Friday) as PRIMARY days, and the two weekend days (Saturday and Sunday) as SECONDARY days.

The way you define days and assign restrictions depends on your site. For example, suppose that on weekdays your system supports a large number of interactive users, but on weekends it is used for certain operations that require dedicated system resources. By assigning restrictions to the SECONDARY day type, you can restrict users from accessing the system during the days defined as SECONDARY. You can change these day type definitions for any account using the following AUTHORIZE qualifier:

/PRIMEDAYS=([NO]day[,...])

The /PRIMEDAYS qualifier uses a list of day names to define the PRIMARY and SECONDARY days of the week. To define a day as a SECONDARY day, use the prefix NO before the day name. Any days you omit from the list take their default value.

6.8.2 Restricting Logins to Specific Times

By default, there are no restrictions on login hours. You can specify login time restrictions using the following AUTHORIZE qualifiers:

Qualifier	Meaning
/[NO]ACCESS	Specifies access hours for all modes of logins
/[NO]DIALUP	Specifies access hours for interactive logins from dialup terminals
/[NO]INTERACTIVE	Specifies access hours for interactive logins from any terminal
/[NO]LOCAL	Specifies access hours for interactive logins from local terminals
/[NO]REMOTE	Specifies access hours for interactive logins from network remote terminals (SET HOST)

Users still logged in when the access time has expired receive the following warning message and have 2 minutes to log out before their processes are terminated by the job controller:

JBC-W-RESTRICT, UAF restricts access at this time, please log out immediately

6.8.3 Restricting Login Functions

In addition to specifying hourly login restrictions, you can assign function restrictions to an account by using appropriate keywords with the /FLAGS qualifier in the Authorize utility. By default, there are no restrictions. Options are shown in the following table:

Keyword	Meaning
[NO]AUDIT	[Do not] audit all security-relevant actions.
[NO]AUTOLOGIN	[Do not] prevent access except by automatic login when automatic logins are enabled.
[NO]CAPTIVE	[Do not] prevent user from changing any defaults at login (implies DISCTLY).
	[Do not] deny user access to the DCL command level.
[NO]DEFCLI	[Do not] prevent user from changing default CLI or CLI tables.
[NO]DISCTLY	[Do not] disable Ctrl/Y interrupts.
[NO]DISFORCE_PWD_CHANGE	[Do not] remove requirement that user must change an expired password at login.
[NO]DISIMAGE	[Do not] prevent user from using the RUN or MCR commands or from executing "foreign" commands.
[NO]DISMAIL	[Do not] prevent mail delivery to the user.
[NO]DISNEWMAIL	[Do not] suppress "New Mail..." announcements.
[NO]DISPWDDIC	[Do not] disable automatic screening of new passwords against a system dictionary.
[NO]DISPWDHIS	[Do not] disable automatic checking of new passwords against list of user's old passwords.
[NO]DISRECONNECT	[Do not] disable automatic reconnection to an existing process when a terminal connection has been interrupted.
[NO]DISREPORT	[Do not] disable reporting of login information (last login date, login failures, and so on).
[NO]DISUSER	[Do not] disable account completely.
[NO]DISWELCOME	[Do not] suppress "Welcome to..." login message.
[NO]GENPWD	[Do not] require user to use generated passwords.
[NO]LOCKPWD	[Do not] prevent user from changing password.
[NO]PWD_EXPIRED	[Do not] mark password as expired.
[NO]PWD2_EXPIRED	[Do not] mark second password as expired.
[NO]RESTRICTED	[Do not] prevent user from changing any defaults at login.

6.8.4 Using Login Command Procedures for Restricted or Captive Accounts

Using the /LGICMD qualifier with the AUTHORIZE commands ADD, MODIFY, or COPY defines the login procedure for a restricted or captive account. A person logging in to such an account cannot modify the procedure with any of the login qualifiers: /CLI, /DISK, /COMMAND, /NOCOMMAND, /TABLES.

The CAPTIVE and RESTRICTED flags perform the following actions:

• Disable the use of Ctrl/Y (/FLAG=DISCTLY); however, a system manager can enable the Ctrl/Y sequence for a restricted account by adding the DCL command SET CONTROL=Y at the end of the login procedure.
• Prevent the use of the SPAWN command from Mail or the use of the SPAWN built-in procedure from the DEC Text Processing Utility (DECTPU).

Once logged in, a person using a restricted account operates from the DCL level and can access any available software.

A person using a captive account is locked into the application software where access to the DCL level is denied, provided the system manager observes the following practices:

• When you need to prompt for and accept direct user input, do not execute the text entered by the user directly; rather, first screen the input, and specifically permit only the set of characters that is valid for the intended use. Reject all characters that are not appropriate for the intended use.
  Prohibit the following character set from user input, as these characters have special meanings to the DCL command interpreter:
  • ampersand (&) and double ampersand (&&)
  • angle brackets (<) (>)
  • apostrophe (')
  • at-sign (@)
  • dollar sign ($)
  • hyphen (-)
  • quotation mark (")
  • semicolon (;)
  • vertical bar (|) and double vertical bar (||)
• Use the DCL command READ/PROMPT in captive account login command procedures because the INQUIRE command is not allowed.
• Set the subprocess limit to 0 to prevent the user from spawning out of the account. Set both the /PRCLM qualifier and the SYSGEN parameter PQL_MPRCLM.

Example

A simple login command procedure for a captive account used for an inventory system might consist of the following commands:

$ DEFINE SYS$DISK DISK$INVENT $ RUN INVENTORY $ LOGOUT

The application program INVENTORY assumes control when the user logs in to the account. Assign the CAPTIVE flag to the login flags field of the captive account UAF record by specifying the AUTHORIZE qualifier /FLAGS=CAPTIVE. Section 6.7.4 shows how to use AUTHORIZE to create a UAF record for a captive account.

Example 6-4 is a command procedure for a highly secure captive account, which restricts the user to a very limited set of commands. System managers must be sure to deny the account owner any write access to the login command procedure and its directory. Note also that the security manager would use the AUTHORIZE qualifier /NOINTERACTIVE when establishing this account.

For more information about captive and restricted accounts, see the OpenVMS Guide to System Security.

Example 6-4 Sample Captive Command Procedure

$ deassign sys$input $ previous_sysinput == f$logical("SYS$INPUT") $ on error then goto next_command $ on control_y then goto next_command $ set control=(y,t) $ $next_command: $ on error then goto next_command $ on control_y then goto next_command $ $ if previous_sysinput .nes. f$logical("SYS$INPUT") then deassign sys$input $ read/end=next_command/prompt="$ " sys$command command $ command == f$edit(command,"UPCASE,TRIM,COMPRESS") $ if f$length(command) .eq. 0 then goto next_command $ $ delete = "delete" $ delete/symbol/local/all $ if f$locate("@",command) .ne. f$length(command) then goto illegal_command $ if f$locate("=",command) .ne. f$length(command) then goto illegal_command $ if f$locate("F$",command) .ne. f$length(command) then goto illegal_command $ verb = f$element(0," ",command) $ $ if verb .EQS. "LOGOUT" then goto do_logout $ if verb .EQS. "HELP" then goto do_help $ $ write sys$output "%CAPTIVE-W-IVVERB, unrecognized command \",verb,"\" $ goto next_command $ $illegal_command: $ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line" $ goto next_command $ $do_logout: $ logout $ goto next_command $ $do_help: $ define sys$input sys$command $ help $ goto next_command

6.8.5 Setting Priorities for User Processes

A user's priority is the base priority used in scheduling the process that the system creates for the user.

On VAX systems, priorities range in value from a low of 0 to a high of 31; 0 through 15 are timesharing priorities; 16 through 31 are real-time priorities.

On Alpha systems, priorities range in value from a low of 0 to a high of 63; 0 through 15 are timesharing priorities; 16 through 63 are real-time priorities.

Processes with real-time priorities are scheduled strictly according to base priority; in other words, the executable real-time process with the highest base priority is executed first. Processes with timesharing priorities are scheduled according to a slightly different principle to promote overlapping of computation and I/O activities.

In the user's account record of the UAF, the default value of a user's priority is 4; for practical purposes, the minimum value is 0. Ensure that the priority for timesharing users remains at the default. Note that if you give some users an advantage over other users by raising their priorities, ragged performance results, because the system reacts sharply to even small base priority differences.

6.9 Setting Up Special Accounts

As system manager, you might need to set up a variety of special accounts, such as automatic login accounts, project accounts, and proxy accounts. The following sections explain how to perform these tasks:

Task	Section
Setting up an automatic login account with SYSMAN	Section 6.9.1
Setting up a project account with ACL identifiers	Section 6.9.2
Creating network proxy authorization files	Section 6.9.4
Adding proxy accounts	Section 6.9.5
Removing proxy accounts	Section 6.9.6
Displaying proxy accounts	Section 6.9.7
Controlling proxy logins	Section 6.9.8

Section 6.9.3 explains what network proxy accounts are.

6.9.1 Setting Up an Automatic Login Account with SYSMAN

The System Management utility (SYSMAN) includes the functions of the automatic login facility (ALF). Using SYSMAN ALF commands, you can set up a terminal that automatically logs in a user to a certain user name. For example, a terminal might be set up for the account INVENTORY, which automatically logs in a user to a captive account when the user presses the Return key.

First, you must follow the steps described in the previous sections to create the top-level default directory and to add the account. Then you can associate the account with a particular terminal or port using the following format:

ALF ADD device user [/TERMINAL] [/PORT] [/PROXY] [/LOG]

where:

device	is the terminal or port name that you want to assign to a user name. Note that device must be a terminal name if you do not specify qualifiers on the command line.
user	is the account user name that you want to assign to a particular terminal or port.
/TERMINAL	causes SYSMAN to treat device as a terminal name. This is the default behavior.
/PORT	causes SYSMAN to treat device as a port name. If the port name contains a special character such as a slash ( / ) or if it contains lowercase letters that you want to preserve, you must enclose the port name within quotation marks. Be aware that anything within quotation marks is written literally to the ALF database file. For example, if the actual port name contains uppercase letters as well as special characters, be sure to specify uppercase letters within the quotation marks. Otherwise, a mismatch will occur between the actual port name and what is specified in the SYSALF.DAT file.
/PROXY	causes SYSMAN to check that device is in the NODE::USERNAME format, which can be up to 63 characters in length.
/LOG	causes SYSMAN to display a message that the device and user have been added to the ALF database.

To protect automatic login accounts, set the AUTOLOGIN flag in the account's UAF record. This flag makes the account available only by autologin, batch, and network proxy.

Examples

The following example shows how to invoke SYSMAN and assign terminal TTA0 to the INVENTORY25 account:

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> ALF ADD TTA0 INVENTORY25

When you create ALF records for proxy accounts, the device parameter can be as long as 63 characters. For example:

SYSMAN> ALF ADD VMS:.ZKO.VMSORG.SYSMAN.CLIENT1::SYSTEM FOOBAR

In this command, VMS:.ZKO.VMSORG.SYSMAN.CLIENT1::SYSTEM is the value of the device parameter.

For more information about autologin accounts and the SYSMAN ALF commands, see the OpenVMS System Management Utilities Reference Manual and the OpenVMS Guide to System Security.

6.9.2 Setting Up a Project Account with ACL Identifiers

This section describes how to set up a project account that uses access control lists (ACLs) to control access to files shared by members of a project group. See the OpenVMS Guide to System Security for complete details on setting up accounts with ACLs.

How to Perform This Task

You must first add an identifier to the rights database for the project account. Use the AUTHORIZE command ADD/IDENTIFIER to add identifiers to the rights database and then associate users as holders of existing ACL identifiers with the AUTHORIZE command GRANT/IDENTIFIER. All users who hold the project's identifier can use the disk space of the project account.

You can set up the project account so that disk space is charged to the project, rather than to individual users, by assigning the resource attribute to the project identifier.

Example

The following example summarizes the steps for setting up a project account:

1. Set up individual user accounts for each member sharing the project account (as described in Section 6.5 and Section 6.6 on adding a user account).
2. Create the project identifier with the resource attribute and grant it to those users who will have access to the project account. In the example that follows, the project identifier KITE_FLYING is given the resource attribute. This identifier is then granted to users GEORGE and LINDORF.

   $ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD/IDENTIFIER KITE_FLYING/ATTRIBUTES=RESOURCE {message} UAF> GRANT/IDENTIFIER KITE_FLYING GEORGE/ATTRIBUTES=RESOURCE {message} UAF> GRANT/IDENTIFIER KITE_FLYING LINDORF/ATTRIBUTES=RESOURCE {message} UAF> EXIT

3. Create the disk quota authorization for the project identifier. For example, the following command invokes SYSMAN and assigns the identifier KITE_FLYING 2000 blocks of disk quota with 200 blocks of overdraft:

   $ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA ADD KITE_FLYING/PERMQUOTA=2000/OVERDRAFT=200 SYSMAN> EXIT

4. Create the project directory. For example, the following DCL command creates the project directory [KITE_FLYING] and establishes the identifier KITE_FLYING as the owner:

   $ CREATE/DIRECTORY [KITE_FLYING]/OWNER=[KITE_FLYING]

5. Set up the necessary ACL and default ACL on the project directory. For example, the following DCL command places an ACL on the directory [KITE_FLYING] that permits any holder of the identifier KITE_FLYING to gain read, write, or execute access to the directory; it also ensures that files created in the directory receive the same ACE (access control list entry) as a default:

   $ SET SECURITY [000000]KITE_FLYING.DIR;1 - _$ /ACL=((DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) - _$ (IDENTIFIER=KITE_FLYING, ACCESS=READ+WRITE+EXECUTE), - _$ (IDENTIFIER=KITE_FLYING,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE))

Access must be granted through ACL entries, because the owner identifier of the directory and the files (KITE_FLYING) does not match the UIC of any of the project members; thus, only world access is available through the UIC-based protection mask. The first ACE of the specified ACL gives all project members read, write, and execute access to the directory; the second ACE gives them read, write, and execute access for all files created in the directory.

Note that project members are not allowed to delete (or control) files created by others. However, the members each have complete access to files that they have created in the directory, because the file system supplies an additional default ACL entry that grants to the creator control access plus the access specified in the OWNER field of the UIC-based protection mask. This ACE appears only when the owner of the created file does not match the UIC of the creator.

Thus, when LINDORF creates the file [KITE_FLYING]THURSDAY.TXT, the file receives the following access control list by default:

(IDENTIFIER=LINDORF,OPTIONS=NOPROPAGATE, ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=KITE_FLYING,ACCESS=READ+WRITE+EXECUTE)

You can use the Creator ACE command in the ACL editor to add an extra ACE to the ACL for a file created within the directory to which you assign the Creator ACE. The Creator ACE applies only when the following conditions exist:

• The file being created is not owned by the user identification code (UIC) of the process creating the file.
• The process creating the file does not have system privileges.

See the OpenVMS System Management Utilities Reference Manual and the OpenVMS Guide to System Security for more information about the Creator ACE.

	privacy and legal statement
6017PRO_022.HTML