Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

submit with /user qualifier

SOLVED
Go to solution
Anthony Silverman
Occasional Advisor

submit with /user qualifier

We have some privileged users who can submit batch jobs with the /user qualifier.

We would like to know which user submitted the job but the show queue command only shows us the username taken from the /user qualifier.

How can we find out which privileged user submitted the job?
6 REPLIES
David Jones_21
Trusted Contributor

Re: submit with /user qualifier

Set audit /enable=privi=cmkrnl/alarm, then
look for the "CMKRNL used to process SJC$_USERNAME item code" events and match the source PID in the accounting file (or live system if they haven't logged out) to get the submiting process.
I'm looking for marbles all day long.
Hoff
Honored Contributor

Re: submit with /user qualifier

There are various ways. Enable and configure the security on the queue via SET SECURITY command; add an alarm or an audit entry onto the queue's ACL. You can catch the PID of the submitter in the alarm or audit, and work from there.

$ set security /class=queue /acl=((alarm=security, access=submit+success)) sys$batch

will get the PID logged, and you can trace from there.

If you're working with cooperating users (as differentiated from a question involving auditing privileged users) (and simply looking for a "who do I talk to"), then you can use the SUBMIT /NOTE from within your local DCL for the submit (most folks have some form of DCL procedure wrappers for this stuff) or the analog available in the $sndjbc itemlist from within executable images.

Having submissions like this and use of DETACH can be quite problematic from the perspective of auditing, too, It can be better to have user-specific entries and usernames or ACLs or such, rather than having some number of folks able to submit to SYSTEM or any user. SUBMIT /USER and DETACH privilege are both very big hammers. Generic accounts are usually bad. And DETACH privilege is a gigantic generic account.
John Gillings
Honored Contributor
Solution

Re: submit with /user qualifier

Anthony,

If SUBMIT/USER is the only reason users have CMKRNL privilege, and you don't need too much flexibility in combinations of qualifiers for the SUBMIT, you can write a program to do the submit with $SNDJBC, which could be installed with CMKRNL, thereby allowing you to remove the privilege from the user accounts.

Your program could keep a (protected) audit log of who submitted what on behalf of whom. It could also limit which users can be the target of the submission.

If there's a very limited set of specific jobs and user combinations that need to be submitted, it's even easier. Just can the whole lot into a privileged image and give the users an interface to select jobs from a menu.

Other than that, as David and Hoff have mentioned, you can enable audits which will record these events, BUT since these users have an ALL class privilege, it's feasible they could modify the audit journals to erase the records of events.

It's all a matter of how much they are trusted. Bottom line, if this is a case of users who are not completely trusted, they should not have CMKRNL or IMPERSONATE privilege.

General principle... if you want to control how a privilege is used, you cannot grant it to a user account. You need to write a program to be installed which limits the operations which can be performed.
A crucible of informative mistakes
Anthony Silverman
Occasional Advisor

Re: submit with /user qualifier

I am going to try the $sndjbc option. It will take more time but it will give me a more complete solution.

I have also just discovered my REAL problem. The submit command has been installed with CMKRNL to allow captive end users to submit jobs under operator usernames. If I write a $sndjbc program I should be able to solve both problems and remove CMRKNL from users and the installed SUBMIT command.
Jess Goodman
Esteemed Contributor

Re: submit with /user qualifier

Or you could do this:

* Copy SUBMIT.EXE to SUBMIT_CMKRNL.EXE
* Set an ACL on SUBMIT_CMKRNL.EXE to restrict access to only the users you trust for this.
* Install SUBMIT_CMKRNL.EXE with CMKRNL priv.

Then the users you gave access to it can do:
$ DEFINE /USER SUBMIT SUBMIT_CMKRNL
$ SUBMIT /USER=...
I have one, but it's personal.
Hoff
Honored Contributor

Re: submit with /user qualifier

I'd probably look to use ACLs first, both on the queue as needed and particularly the addition of identifiers and resource identifiers and ACLs in the context of the target environment.

From an auditing perspective, that approach is usually easier and cleaner as it avoids swapping user contexts. Identifiers and subsystem identifiers and resource identifiers can be very targeted, or can be set up for broad access.