- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: submit with /user qualifier
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2009 05:40 AM
тАО06-11-2009 05:40 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2009 06:00 AM
тАО06-11-2009 06:00 AM
Re: submit with /user qualifier
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2009 06:33 AM
тАО06-11-2009 06:33 AM
Re: submit with /user qualifier
$ 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-11-2009 02:21 PM
тАО06-11-2009 02:21 PM
SolutionIf 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-12-2009 01:03 AM
тАО06-12-2009 01:03 AM
Re: submit with /user qualifier
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-12-2009 07:57 AM
тАО06-12-2009 07:57 AM
Re: submit with /user qualifier
* 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=...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-12-2009 08:17 AM
тАО06-12-2009 08:17 AM
Re: submit with /user qualifier
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.