.save .page size 58,73 .flags overstrike .flags bold .enable bolding .keep .nast .nap .no headers .page size 48,72 .left margin 8 .! note to Pageswapper Editor: if you change the left margin, .! pleasee also change the number of "#" characters at the .! beginning of each .subtitle ########text .right margin 72 .spacing 1 .no fill .nojustify .paging .c;^*System Security and Student Operators\* .c;^*^&DO\& Mix.\* .c;John D. Hoinville .c;and .c;Richard D. Piccard .c;Educational Computing .c;Kalamazoo College .c;Kalamazoo, Michigan .headers ^&Abstract\& We present techniques through which ^&all\& VMS user and system disk backups can be performed by operators whose ^&only\& extra user authorization entries are for the "OPER" and "GRPNAM" privileges and an identifier such as "STUDENT__OPERATOR". We place Access Control Lists on the tape and removable-media disk drives that deny access to ^&all\& users (including the operators) except those who have "BYPASS" privilege or a specific identifier. These methods have two primary advantages: all user disk backups are performed by command procedures, which reduces to minimal levels the chance of a catastrophic mistake, and the operators can legitimately be advertised to have ^&no\& special access to the files they are backing up. ^&I. Introduction\& .subtitle ########Student Operators: Introduction It is difficult to resolve the conflicting goals of system security; file system invulnerability to hardware, software, or human failures; system availability to users (measured both in connect time and CPU cycles), especially during normal working hours; and the effective use of professional staff time. At Kalamazoo College we have developed a method of meeting the file backup goal that has minimal impact on our ability to meet the other goals. Although there are some refinements that require recent VMS updates, variations of these techniques should be usable on any VMS Version 4 system. The approach described here should be of particular interest for small educational installations, but many other sites cannot afford to use skilled programmers as operators either. This paper is organized into four sections, as revealed by the outline, below: .lm+6 I. Introduction II. Preparation A. Maintaining Operator Accounts B. Boot-time Measures C. File Access Control Lists III. Daily Operations A. Professional Staff B. Student Operators IV. Conclusion .lm-6 The heart of our approach is to perform all backups and system shutdowns from batch jobs that are submitted, /AFTER= a date in the far future, by user SYSTEM (or by someone else with "BYPASS" privilege). The student operator is granted access to the batch jobs' log files by an ACL entry that is automatically propagated to succeeding versions. The student operator can manipulate the queue to release or suspend a job, having OPER privilege. However, the student operator ^&cannot\& read other people's private files directly, having ^&neither\& BYPASS nor READALL privileges, and also ^&cannot\& read them indirectly from the removable media (disk or tape) backup copies, because of Access Control List entries on the drives. The hard parts are first, getting the identifiers, ACLs, and privileges done correctly (examples are included below) and second, creating a batch job to shut the system down, since the queue manager and all batch jobs vanish like the Cheshire Cat fairly early in the shutdown process! The solution to the second problem is to have the batch job (which is ^&released\& by the student operator) include a RUN/DETACHED command to create a process that will shut the system down. This process is ^&outside\& the purview of the job controller, hence survives the early shutdown of all queues. .test page 10 ^&II. Preparation\& A. Maintaining Operator Accounts .subtitle ########Student Operators: Preparation Our student operators use two accounts. The first is their personal student account, which has no special privileges or identifiers at all. The second is one of several long term accounts (usernames of the form OPERATORn, for n = 1, 2, ...) whose password is changed every academic term and whose OWNER field in SYSUAF.DAT is also changed to indicate the student presently authorized to use it. It is the OPERATORn accounts that have the STUDENT__OPERATOR identifier and the OPER and GRPNAM privileges. There are three steps involved in maintaining the student operator accounts: original creation, modification to operator functionality, and modification upon staff turnover. The original creation is by standard techniques, such as the ADDUSER.COM file presented in example 5-4 of the "Guide to VAX/VMS System Management and Daily Operations." Take pains to use a UIC code that gives all of the OPERATORn accounts the same group number, with no other users having that group number. The AUTHORIZE utility is used once interactively to create the STUDENT__OPERATOR identifier and later through a command procedure to grant it to the individual operator accounts. Using the OPERATORn accounts also helps for dealing with turnover in student workers. When a student leaves, only the OPERATORn account he or she used need be modified. This keeps management of the OPERATORn accounts (and hence, who has access to the OPER and GRPNAM privileges) to a minimal level. Appendix 1 shows an example command procedure that uses AUTHORIZE to modify newly created operator accounts so that they can function as such. As with all of our other examples, filenames specified assume that the directory SYS$MANAGER: is used as the location of these files. Since this directory is one of the ones that are manipulated during the upgrades for even-numbered VMS releases (e.g., 4.2 and 4.4), we actually locate all of these files in a site specific directory (in our case, SYS$SYSDEVICE:[KALAMAZOO.MANAGER]). This results in a modest reduction in system down time during those major upgrades, because fewer files have to be renamed back and forth. Appendix 2 shows an example command procedure that is used at the beginning and end of each academic term. At the beginning of the term it establishes the password and student operator (owner) name. At the end of the term, it disables the account. .test page 10 B. Boot-time Measures .c;ACLs for Devices Since the tape and removable media disk drives are being used by the operator, the protection of those devices is especially important. There are often extended periods of time when previously used tapes or disk packs are physically mounted. This could constitute a terrible security hole, since the operators or other users might allocate the drive, mount the volume, and read the contents. The backup command procedure does indeed allocate the device, so that no interference will occur while it is in use, but that happens only when it is actually time to write the new backup copies of the files. We escape from this nightmare, as shown in Fig. 1, by the simple expedient of placing Access Control Lists (ACLs) on the drives. .page ================================================================ | Figure 1 | ============ $! $! Set protection so that users with the identifier $! EDCOMPSTAFF can access tape and disk drives. $! $ EDCOMP :== SET DEVICE/ACL=(- (IDENTIFIER=EDCOMPSTAFF,- ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL), - (IDENTIFIER=[_*,_*], ACCESS=NONE)) $! $ EDCOMP MSA0: $ IF ("''f$trnlnm("sys$sysdevice")'" .NES. "DJA0:") - THEN EDCOMP DJA0: $! .c;Figure 1: Creating Device ACL's in SYSTARTUP.COM. ================================================================ The ACLs achieve several useful functions: the professional staff (who have need, or who know the SYSTEM passwords, and hence could get to it anyway) are granted full access to the drives; any job, typically with [SYSTEM] UIC, that has BYPASS privilege (such as the BACKUP jobs) gets access anyway; all other processes are ^&denied\& access, including ordinary users ^&and\& the student operators. The ACL is applied to the RA-60 only if it is ^¬\& the system disk, since users MUST have access to many files on the system disk! .test page 7 .c;Group Logical Names The student operators use their group logical name table to communicate to the backup batch job in the event that a fatal error or other catastrophe requires that the BACKUP command itself be re-issued. As discussed in part III, our backup command procedure includes code (removed from our example in Appendix 3) that must be executed only once, so that re-trying the BACKUP command must be possible. Besides, what system manager likes to be awakened by a phone call at at 6:20 AM from the student operator asking to have the backup job re-submitted! In order for the group logical name table to exist, at least one name must continue to be defined in it. Figures 2 and 3 show how this is done; the input command procedure specified in Fig. 2 is presented in Fig. 3. The technique of running LOGINOUT to process a DCL input file was documented in the Release Notes for VMS V4.1, page 4-2 (thanks go to the Colorado Customer Support Center staff for digging up this reference). ================================================================ | Figure 2 | ============ $! $! Run the job that creates the operator group [50,_*] $! logical name table, for use by BATCH__SUBSETBACK. $! $ RUN/DETACH/UIC=[OPERATOR1]- /INPUT=SYS$MANAGER:OPERATOR__LNMTBL.COM- /OUTPUT=SYS$MANAGER:OPERATOR__LNMTBL.LOG- /PROCESS__NAME=OPERATOR__LNMTBL- SYS$SYSTEM:LOGINOUT $! .c;Figure 2: Creating Group Logical Names in SYSTARTUP.COM. .c;(Input file is presented in Fig. 3.) ================================================================ .page ================================================================ | Figure 3 | ============ $ DEFINE/GROUP STUDENT__OPERATOR__GROUP - "DO__NOT__DELETE__THIS__LOGICAL__NAME" $! $ EXIT $! $! +++++++++++++++++++++++++++++++++++++++ $! $! SYS$MANAGER:OPERATOR__LNMTBL.COM $! $! Executed by a RUN/DETACH/UIC=[OPERATOR] command in $! SYSTARTUP so that the [50,_*] group logical name table $! will exist for reference by BATCH__SUBSETBACK.COM. $! $! +++++++++++++++++++++++++++++++++++++++ .c;Figure 3: Input file for creating the OPERATORn .c;group logical name table (see Fig. 2). ================================================================ .c; PRIVBATCH The backup and system shutdown batch jobs are submitted to a privileged (or private) batch queue, PRIVBATCH, so that they cannot be shut out by user jobs. That queue is created as shown in Fig. 4. The memory management values proved essential for efficient analysis of accounting data, they are extravagent for backups. (Before we learned how large to set WSEXTENT, one quarterly accounting summary provoked 6 million page faults!) .page ================================================================ | Figure 4 | ============ $! $ INITIALIZE/QUEUE/BATCH/START/JOB__LIMIT=5- /WSDEFAULT=1024/WSQUOTA=3500/WSEXTENT=3500- /BASE__PRIORITY=4/PROTECTION=(S:RWED,O,G,W) - PRIVBATCH $! .c;Figure 4: Creating PRIVBATCH in SYSTARTUP.COM. ================================================================ .test page 6 C. File Access Control Lists In order to allow a student operator to monitor the command procedures for errors, including BACKUP's soft tape write errors (which we track as an indicator of wear on re-cycled tapes), the student is granted the STUDENT__OPERATOR identifier. By giving the log files the correct ACLs, the student operators can access these files while leaving the rest of SYSTEM's log files secure from browsing. This reduces temptation the student operators might experience when it comes to looking into areas where they should not be allowed. Figure 5 shows the protection of a typical backup log file. Two methods can be used to create ACLs for the log files. One method is to set the ACL for the file with the VMS "SET ACL" command, the other method is to EDIT/ACL the file. An example of the former method is as follows: .test page 4 $ SET ACL/ACL=(IDENTIFIER=STUDENT__OPERATOR, - ACCESS=READ) EX.LOG Note, that if this file had an existing ACL associated with it, this new ACL entry would be put to the top of the ACL list. The new entry could instead be added to the end of the ACL list with the "/AFTER" option. ================================================================ | Figure 5 | ============ $ DIR/SECUR SYS$MANAGER:BATCHBACK.LOG Directory SYS$SYSROOT:[SYSMGR] BATCHBACK.LOG;24 [SYSTEM] (RWED,RWED,RE,) (IDENTIFIER=STUDENT__OPERATOR,ACCESS=READ) .c;Figure 5: Log file ACL. ================================================================ Another way to create or modify an ACL is to invoke the ACL editor. By using the ACL editor, a file with the correct ACL can be created and then other files can be given the same ACL using the command $ SET ACL/LIKE=OBJECT__NAME=filename__with__ACL - filename__needing__ACL This command was not correctly described in early VMS Version 4 documentation. .test page 10 ^&III. Daily Operations\& A. Professional Staff .subtitle ########Student Operators: Daily Operations .c; BACKUP jobs The student operators can control the start of the backup because the submission command specifies execution at a later date that is hundreds of years in the future, so that the job will not run until an operator intervenes. Because of the complexity of the submission command, the system manager uses an interactive command procedure to perform the submission. We have such procedures for submitting the jobs that will perform overnight backups of new files, that will shut the system down for standalone backup of the system disk, that will perform full backups of specific user file directory trees, etc.. .save .fn .nj .sp1 .b2 .restore ================================================================ | Figure 6 | ============ $ BEGIN: $! $ IF P1 .NES. "" THEN GOTO START $ INQUIRE/NOPUNCT P1 - "SUPPLY SAVE SET NAME (e.g., SYSTEMC.BCK): " $ GOTO BEGIN $! $ START: $! $ SUBMIT/QUEUE=PRIVBATCH/NOTIFY/PARAMETERS=("''P1'") - /NOPRINTER SYS$MANAGER:RA60BACKUP.COM - /NAME=BATCH__RA60BACKUP/AFTER=18-SEP-3500 $! $ EXIT .c;Figure 6: A Simplified Submission Procedure. ================================================================ .efn Figure 6 shows the critical portion of the commmand procedure that submits the procedure BATCH__RA60BACKUP.COM, which we use to write tape copies of RA-60 packs, typically the oldest existing disk pack copy of the system disk. The procedure prompts for the saveset name if the name was not supplied. Once a saveset name is supplied, the backup procedure is submitted to the batch queue named PRIVBATCH, for execution after the 18th of September in the year 3500. Of course that wait will never be fulfilled; the job is held until an operator intervenes, as discussed in part B of this section. By having the queue manager hold the job, there is virtually no CPU or memory used until it is actually time to execute the backup. In these respects it is superior to our original inspiration. That involved submission, by the backup or shutdown job, of another job that consisted of an infinite loop of 23 hour WAIT commands. Then, in the backup or shutdown job, that submission was followed by a SYNCHRONIZE command. When the time came to proceed, the student operator would delete the WAITing job, which would satisfy the SYNCHRONIZE and release the backup or shutdown job. This was clumsy, but it did work. It required a separate queue ("SYNCQUEUE"), consumed memory for both jobs, as well as a little CPU for the WAIT loop, and consumed active job slots in the PRIVBATCH queue. On our system we have located all user files in a directory tree whose root is DUA1:[USERFILES]. The files are split into three groups, in subdirectories MONDAY, WEDNESDAY, and FRIDAY, and the pseudodevices MON:, WED:, FRI:, and USER: are defined at boot time by the logical name assignments in Fig. 7. (USER: is a search list for the other three, for use when you don't know which group a given user's files are in.) We backup all files in each subtree once a week, on the obvious day. ================================================================ | Figure 7 | ============ $ ASSIGN/EXEC/SYSTEM/TRANSLATION=(CONCEALED,TERMINAL) - DUA1:[USERFILES.FRIDAY.] FRI: $ ASSIGN/EXEC/SYSTEM/TRANSLATION=(CONCEALED,TERMINAL) - DUA1:[USERFILES.WEDNESDAY.] WED: $ ASSIGN/EXEC/SYSTEM/TRANSLATION=(CONCEALED,TERMINAL) - DUA1:[USERFILES.MONDAY.] MON: $! $ ASSIGN/EXEC/SYSTEM FRI:,WED:,MON: USER: $! .c;Figure 7: Creating pseudodevices in SYSTARTUP.COM. ================================================================ A simplified user file backup command procedure is shown below, in Appendix 3. The procedure we actually use also performs several tasks at the beginning and end on specific days. Some of these we do ^¬\& want repeated, so provision must be made to loop back over the BACKUP command itself in case something should be wrong (fatal tape drive error, etc.). That is done through a group logical name for the student operators' UIC group (50 in our case). An alternative method to achieve the batch mode equivalent of the interactive INQUIRE command would be to write a program (in MACRO, FORTRAN, or PASCAL) that uses the SNDOPR (or SYS$SNDOPR) system service, which is documented on pages SYS-429 through SYS-442 of the ^&VAX/VMS System Services Reference Manual.\& Once the program has captured the text of the operator's reply, that text can be passed on to DCL through the LIB$SET__SYMBOL routine. We chose to implement the group logical name approach, rather than the SNDOPR approach, because the code is simpler and we could implement it with confidence more rapidly. Even if information more complex than a YES or NO type choice must be communicated, the group logical name approach should be considered. It will not work, of course, unless the batch process and the operator have either the same UIC group number, an identifier that matches an ACL on the group logical name table, or BYPASS privilege. (See the PAGESWAPPER for April, 1986, pages VAX-2 and VAX-3 for techniques of placing ACL's on logical name tables.) .c; SHUTDOWN for S/A BACKUP Figures 8 and 9 provide the means for the student operator to shut the system down. Figure 8 is the batch job, submitted /AFTER=18-SEP-3500 by SYSTEM, and Fig. 9 is the input command file for the process that it creates after the operator releases it. There is no EXIT at the end of Fig. 9, because by then the system is shut down! This is essentially a variation on the technique used to create the group logical name table: run LOGINOUT so that DCL is available, and specify a command procedure as the input. Here, the input command procedure invokes SYS$SYSTEM:SHUTDOWN, with parameters specified so that no interactive session takes place. Presumably we are vulnerable here to changes in the parameter definitions of SHUTDOWN that DIGITAL might choose to make in future versions of VMS (are you listening, developers?). ================================================================ | Figure 8 | ============ $ SET NOON $ ON ERROR THEN EXIT $ SET LOGINS/INTERACTIVE=0 $ REPLY/USER/BELL/BELL - "THE SYSTEM IS SHUTTING DOWN FOR BACKUPS. PLEASE LOGOUT!" $ WAIT 0:2:0 $! $! Start detached process to shutdown the system $! $ RUN/DETACH/UIC=[SYSTEM]- /INPUT=SYS$MANAGER:CALL__SHUTDOWN.COM- /OUTPUT=SYS$MANAGER:SHUTDOWN.LOG- /PROCESS__NAME=CALL__SHUTDOWN - SYS$SYSTEM:LOGINOUT $! $ EXIT $! $! $! +++++++++++++++++++++++++++++++++++++++ $! $! SYS$MANAGER:BATCH__SHUTDOWN.COM $! $! Allows an operator to bring the system down. $! $! $! +++++++++++++++++++++++++++++++++++++++ .c;Figure 8: SHUTDOWN Procedure Batch job. ================================================================ .page ================================================================ | Figure 9 | ============ $ ASSIGN OPA0: SYS$OUTPUT $ DEL_*ETE :== DELETE/NOCONFIRM $ SET NOVERIFY $ @SYS$SYSTEM:SHUTDOWN 0 "Standalone backup" "N" "Y" - "BY 8 AM" "N" "REBOOT__CHECK" $! $! +++++++++++++++++++++++++++++++++++++++ $! $! SYS$MANAGER:CALL__SHUTDOWN.COM $! $! SHUTDOWN.COM parameters have the following meanings: $! $! P1 = Minutes until shutdown $! P2 = Reason for shutdown $! P3 = Spin down disk volumes $! P4 = Invoke site-specific shutdown procedure $! P5 = When will the system be rebooted? $! P6 = Perform automatic reboot? $! P7 = Shutdown option $! $! +++++++++++++++++++++++++++++++++++++++ .c;Figure 9: SHUTDOWN Procedure Detached job input. ================================================================ .test page 11 B. Student Operators .c; BACKUP Jobs The OPERATORn accounts have a LOGIN.COM that includes REPLY/ENABLE and then REPLY/STATUS to find out whether any outstanding requests need to be satisfied (such as mounting a second tape volume for the overnight backup). If such is the case, then the operator mounts the next tape and issues a command of the form $ REPLY/TO=request-number using the request number indicated by the REPLY/STATUS output. The operator checks the overnight incremental backup log file (with an EDIT/TPU/READ__ONLY command) to verify that all went well. Once the incremental backup is completed, the operator finds and mounts the first tape for that day's backup. Then the backup job needs to be released. There are two steps, first, find the entry number and, second, then SET that entry of the QUEUE to /NOAFTER as follows: $ SHOW QUEUE/BATCH/ALL PRIVBATCH . . . $ SET QUEUE/ENTRY=entry-number/NOAFTER PRIVBATCH After the above command is entered, the command procedure is immediately queued up for execution. The operator replies to mount requests and problems that may arise during the backup. The first request is usually that the operator mount a tape. The syntax of the reply is as discussed above. When each reel is finished, the operator receives another request to mount the next volume, loads the next tape, and replies to the request. If the procedure makes a request to "REPLY TO CONTINUE, USE DELETE/ENTRY= etc. TO ABORT JOB", then the procedure has encountered an error. ^&Before responding\&, the operator logs in on a screen terminal and edits the log file with the command: $ EDIT/TPU/READ SYS$MANAGER:BATCH__SUBSETBACK.LOG If the only errors are "file access" errors that occured while backing-up the files or "file not found" errors that occurred during the verify or the recording pass, or verification errors for blocks in MAIL or directory files, then all is normal for backups performed on an active system and the operator continues the procedure by replying to the request. If there is a FATAL type error message during the backup, we want to have it re-do just the tape writing part of the procedure. That will happen if, ^&before\& replying, the following line is executed by OPERATORn: $ ASSIGN/GROUP "SHUCKS" BACKUP__ABORTED Then the operator replies to the request so that the procedure continues. As shown in Appendix 3, immediately following the BACKUP (but not executed until after the REPLY, if BACKUP exits with warning or worse status) is a check of the logical name BACKUP__ABORTED in the group table for the [OPERATORn] UIC. If such a catastrophe has happened, and the above recovery started, then the request "Reply when FIRST tape is ready again." will appear. The operator waits for the tape on the drive to rewind and then mounts the ^&first\& volume of the tape set, again, and replies to the request. ^&As soon as\& the backup is underway successfully, the following command must be issued by the operator, ^&before\& the backup completes: $ DEASSIGN/GROUP BACKUP__ABORTED In summary, the logic in BATCH__SUBSETBACK.COM is to test, immediately following completion of the tape-writing, whether the logical name BACKUP__ABORTED has any translation; if it does, then the procedure loops back to the BACKUP command itself. If one reel has a problem, the operator may get a message like "Request 8, Continue, Retry, or Abort". In that case the usual correct response is $ REPLY/TO=8 "RETRY" When the subset backup has completed, the operator ^&types\& the log file on the operator's console, with the command: $ TYPE SYS$MANAGER:BATCH__SUBSETBACK.LOG.0 This maintains a hardcopy record of these operations. .test page 8 .c; SHUTDOWN and S/A BACKUP We instruct our student operators to use the REPLY/USER command to inform current users that a shutdown is impending. If time is not too pressing, the operator waits until all users have logged off before releasing the batch job to shut the system down (see Fig. 8). That job itself sets interactive logins to zero, announces the impending shutdown, and waits another two minutes. This extra time is invested as a matter of policy, to be sure that even if the student operator neglects to announce the shutdown, our users will have had fair warning. Stand-alone BACKUP of the system disk is perhaps the most delicate of the procedures that we entrust to student operators. If they type the BACKUP command with the device names in the reversed order, then the system disk will be wiped out! We do reduce our vulnerability by ^¬\& pre-initializing the disk pack that they are supposed to be writing onto (but in this disaster scenario would copy from). Thus an older copy of the system disk would be "restored" and only software updates, batch jobs pending, and user authorization file changes, made during the intervening period (three weeks as we do these things), would be lost. All but the last week's worth would be recoverable from other packs. After the system has rebooted, the operator logs in and uses REPLY/ALL to notify waiting users that the system is up for the day. .test page 8 ^&IV. Conclusion\& .subtitle ########Student Operators: Conclusion Performing backups from batch jobs liberates the operator, whether professional or student, from having to loiter in the machine room. Instead, we can perform useful work while the backups are in progress, knowing that OPCOM will alert us to the need to change volumes. In addition, the techniques described here permit less-skilled operators to relieve the more skilled staff both of the need to arrive in the wee hours to initiate backup jobs, and also of the time consuming tasks of supervising command procedures and changing tape volumes. We would like to thank several people who have contributed to the development of the techniques reported here. Amy Courter and Mary Haug developed the command procedures used for daily operation of our system, including earlier versions of the backup procedure shown in Appendix 3. Forrest Piehl created the initial versions of the techniques reported here (using the SYNCHRONIZE command, as discussed above in section III, part A), including the code shown in Figs. 8 and 9 that permits student operators to shut the system down for stand-alone backup of the system disk. Finally, we thank the student operators who had to learn and deal with the various modifications and changes as we debugged each new inspiration: Kelly Baldrica, Daryl Dickhudt, Kenneth Dietz, In Bum Eom, Ernest Johnson, and Greg Lewis. ================================================================ | Appendix 1 | ============== $ ON ERROR THEN EXIT .subtitle ########Student Operators: Appendix 1 cont. $ OPEN/WRITE UAF__COM SYS$MANAGER:OPER__GEN.TMP $! $! If P1 was not supplied then INQUIRE for it. $! $ GET__USERNAME: $! $ IF P1 .NES. "" THEN GOTO GENESIS $ INQUIRE/NOPUNCT P1 "Username: " $ GOTO GET__USERNAME $! $! Write command procedure to alter account. $! $ GENESIS: $! $ WRITE UAF__COM "$ SET DEFAULT SYS$SYSTEM:" $ WRITE UAF__COM "$ RUN AUTHORIZE" $ WRITE UAF__COM - "MODIFY ''P1'/PRIV=(GRPNAM,OPER)/DEFPRIV=(GRPNAM,OPER)" $ WRITE UAF__COM - "GRANT/IDENTIFIER STUDENT__OPERATOR ''P1'" $ WRITE UAF__COM " EXIT" $ CLOSE UAF__COM $! $! Run command procedure to modify operator account. $! $ ON WARNING THEN GOTO ABORT__UAF__COM $ @SYS$MANAGER:OPERATOR__GEN.TMP $ ON WARNING THEN EXIT $! $! Cleanup and exit. $! $ DELETE/NOCONF SYS$MANAGER:OPERATOR__GEN.TMP._* $ EXIT $! $! $ ABORT__UAF__COM: $! $ WRITE SYS$OUTPUT - "Error modifying user ''P1'." $ WRITE SYS$OUTPUT - "User ''P1' not modified." $ EXIT $! .test page 17 $! +++++++++++++++++++++++++++++++++++++++ $! $! Used to transform an account generated by the normal $! means into an operator's account. This includes $! giving the account OPER and GRPNAM privileges and the $! STUDENT__OPERATOR identifier. $! $! P1 = Username of account to be transformed. $! $! +++++++++++++++++++++++++++++++++++++++ .c;Appendix 1: Using AUTHORIZE to modify a .c;newly created OPERATORn account. ================================================================ .subtitle ########Student Operators .page ================================================================ | Appendix 2 | ============== $ ON ERROR THEN GOTO ABORT .subtitle ########Student Operators: Appendix 2 cont. $ OPEN/WRITE UAF__COM SYS$MANAGER:OPER__MAIN.TMP $! $! If P1 was not supplied then INQUIRE for it. $! $ GET__USERNAME: $! $ IF P1 .NES. "" THEN GOTO NAME $ INQUIRE/NOPUNCT P1 "Username: " $ GOTO GET__USERNAME $! $ NAME: $! $ IF P2 .EQS. "" THEN GOTO DISUSER $! $! If there is a new operator, then change account $! owner, set login flags, and set a new password. $! $ RENAME__ACCOUNT: $! $ USER :== "NODISUSER" $ MAIL :== "NODISMAIL" $ OWNER :== "''P2'" $ SET TERMINAL/NOECHO $ INQUIRE/NOPUNCT PASS "New password: " $ INQUIRE/NOPUNCT VERIF "Verification: " $ IF "''PASS'" .NES. "''VERIF'" THEN GOTO RENAME__ACCOUNT $! $ SET TERMINAL/ECHO $ PWD :== "/PASSWORD=''PASS'/PWDEXPIRED" $ GOSUB WRITE__OUT $ GOTO CHANGE $! $! Disuser operator account, because P2 equals "". $! $ DISUSER: $! $ USER :== "DISUSER" $ MAIL :== "DISMAIL" $ OWNER :== "SYSTEM__DISUSERED__ACCOUNT" $ PWD :== "" $ GOSUB WRITE__OUT $! $! Run command procedure to modify operator account. $! $ CHANGE: $! $ ON WARNING THEN GOTO ABORT__UAF__COM $ @SYS$MANAGER:OPER__MAIN.TMP $! $ ON WARNING THEN EXIT $ DELETE/NOCONFIRM - SYS$MANAGER:OPERATOR__MAIN.TMP._* $ EXIT $! $ ABORT: $! $ EXIT $! $! If there is an error in AUTHORIZE then write message $! and exit. $! $ ABORT__UAF__COM: $! $ WRITE SYS$OUTPUT - "OPERS-MOD-ERROR, Error modifying user ''P1'." $ WRITE SYS$OUTPUT - "OPERS-STA-ERROR, User ''P1' not modified." $ EXIT $! $! Subroutine to Write command procedure to alter account. $! $ WRITE__OUT: $! $ WRITE UAF__COM "$ SET DEFAULT SYS$SYSTEM:" $ WRITE UAF__COM "$ RUN AUTHORIZE" $ WRITE UAF__COM - "MODIFY ''P1'/OWNER=''OWNER'/FLAGS=(''USER',''MAIL')''PWD' $ WRITE UAF__COM " EXIT" $ CLOSE UAF__COM $ RETURN 1 $! .test page 23 $! +++++++++++++++++++++++++++++++++++++++ $! $! Used to modify an operator account between active and $! inactive status, depending on P2: if P2 equals "", then $! the account is deactivated by setting login flags $! DISUSER and DISMAIL; if P2 is a non-empty string, then $! P2 becomes the owner of the account, the account is $! given a new password, and the login flags are set to $! NODISUSER and NODISMAIL. $! $! P1 = Username of account to be modified. $! P2 = Either name of student to get operator $! account, or "" to disuser account. $! $! +++++++++++++++++++++++++++++++++++++++ .c;Appendix 2: Using AUTHORIZE to modify OPERATORn .c;accounts between academic terms. ================================================================ .subtitle ########Student Operators ================================================================ | Appendix 3 | ============== $ ON WARNING THEN REQUEST/REPLY - "REPLY TO CONTINUE, USE DELETE/ENTRY= etc. TO ABORT JOB" .subtitle ########Student Operators: Appendix 3 cont. $! $ IF P2 .NES. "" THEN THEDAY :== 'P2' $ IF P2 .EQS. "" - THEN THEDAY :== 'F$CVTIME("TODAY",,"WEEKDAY")' $! $ IF THEDAY .EQS. "MONDAY" THEN GOTO GOODDAY $ IF THEDAY .EQS. "WEDNESDAY" THEN GOTO GOODDAY $ IF THEDAY .EQS. "FRIDAY" THEN GOTO GOODDAY $ TYPE SYS$INPUT DAY (P2) MUST BE MONDAY, WEDNESDAY, OR FRIDAY. >>>> NO BACKUPS WERE PERFORMED! <<<< $ EXIT $! $ GOODDAY: $! $ SHORTDAY :== 'F$EXTRACT(0,3,THEDAY)' $ PLUMMET :== - """WE ARE ABOUT TO BACKUP "'THEDAY'" FILES.""" $ REPLY/USER/BELL 'PLUMMET' $ REQUEST/REPLY "REPLY WHEN TAPE IS READY" $ TAPNAME :== WEEK'P1'.'SHORTDAY' $ ANNOUNCE__FILE :== - """@SYS$SYSTEM:ANNOUNCE__"'SHORTDAY'".TXT""" $ ASSIGN/SYSTEM 'ANNOUNCE__FILE' SYS$ANNOUNCE $! $! Issue the backup command $! $ GOTO WRITE__THAT__TAPE $! $ WHAT__WRITE__IT__AGAIN: $! $! Get here only if first try at BACKUP fails. $! $ DISMOUNT/UNLOAD MSA0: $ DEALLOCATE MSA0: $ REQUEST/REPLY - "Reply when FIRST tape is ready again." $! $ WRITE__THAT__TAPE: $! $ SET VERIFY $ ALLOCATE MSA0: TAPE $ MOUNT TAPE /FOREIGN $! $ BACKUP/REWIND/BUFFER=5/RECORD - /JOURNAL=SYS$MANAGER:WEEKLYJOU.LOG - DUA1:[USERFILES.'THEDAY'...]_*._*;_* MSA0:'TAPNAME' $! $! The following logical name will exist only if $! the operator has assigned it after detecting a problem $! requiring that the tapes be re-written. $! $ IF (''F$TRNLNM("backup__aborted","LNM$GROUP__000050") - .NES. "") THEN GOTO WHAT__WRITE__IT__AGAIN $! $! Reach here after a successful BACKUP $! $ DISMOUNT/UNLOAD MSA0: $ DEALLOCATE MSA0: $ ASSIGN/SYSTEM - "@SYS$SYSTEM:ANNOUNCE.TXT" SYS$ANNOUNCE $ UNPLUMMET :== - """WE HAVE FINISHED BACKING UP "'THEDAY'" FILES.""" $ REPLY/ALL/BELL 'UNPLUMMET' $ ON WARNING THEN CONTINUE $! $ EXIT $! .test page 20 $! $! +++++++++++++++++++++++++++++++++++++++ $! $! SYS$MANAGER:BATCH__SUBSETBACK.COM $! $! $! Parameters: P1 = two digit week number, e.g., $! 04 during the fourth week of the term $! P2 = day of the week to backup, if NOT $! current day of the week (Monday, $! Wednesday, or Friday). $! $! +++++++++++++++++++++++++++++++++++++++ .c;Appendix 3: Simplified BACKUP Procedure. ================================================================ .no subtitle .restore