| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1398.1 | | SNOFS1::ELLISS | Are you all sitting too comfybold square on your botty? - Then we'll begin | Wed Oct 02 1996 19:16 | 3 |
| Well, it runs under the SYSTEM username, so set up the SYSTEM account on your box
Shaun
|
| 1398.2 | Don't think that will work | CHOWDA::GLICKMAN | writing from Newport,RI | Mon Oct 07 1996 10:42 | 5 |
| If what you mean is to create an entry in PCM for the SYSTEM account
according to the documentation (User's Guide page 3-34) it won't
work. PCM will use the defaults. Am I missing something?
Thanks.
|
| 1398.3 | | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Tue Oct 08 1996 13:59 | 21 |
| Nope. You are correct. The SYSTEM username always has access to all
PCM functions.
The biggest challenge to overcome has to do with the fact that there is
no /USERNAME qualifier on the RUN/DETACH command because there is
no "username" argument to the $CREPRC system service.
RUN/DETACH/AUTHORIZE is not good enough becuase you still wind up using
the username of the process that called RUN/DETACH and thus the C3
started during boot has username SYSTEM. One could write some
privileged code to change the username of the process. Without proper
protection of that image, you'd have a security hole big enough to
drive a truck through. The Quick and Dirty method is to take advantage
of the /USERNAME qualifier of the SUBMIT command. Write another
procedure that runs in BATCH and set the DECW$MAINAPP symbol so that
it submits this procedure to batch using the /USERNAME qualifier. This
procedure will then RUN/DETACH the procedure that runs the C3. This
will prevent tying up a batch queue and prevent an operator from
stopping the C3 accidentaly if they muck with the queue manager.
Regs,
Dan
|