- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- SYSLCK privileges - What are the dangers
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
тАО04-26-2010 10:10 AM
тАО04-26-2010 10:10 AM
This just won't go away.
We have an ALPHA software package RS/1 that I used the AEST translation program to successfully move to the Integrity server. It works, but requires that the users of it are granted SYSLCK privilege. It can't be installed with priv.
What I need to understand, and convey to management, is what are the dangers and potential damages, of giving SYSLCK to a number of users ?
The 2-3 lines of the manual are too enlightening.
Thanks !
-jg-
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 10:53 AM
тАО04-26-2010 10:53 AM
Re: SYSLCK privileges - What are the dangers
areN'T
ftfm
-jg-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 12:28 PM
тАО04-26-2010 12:28 PM
Solutionhttp://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1422114
The simple answer is what you were given in that thread.
Do it.
For a handful of even mildly trusted folks and as an expediency and given the code already works, there is no risk here.
Now as for what this means for someone seeking technical details, the user will be able to queue so-called system-wide locks. Which the OpenVMS documentation states: "When you specify this [SYSTEM] flag, the resource name is interpreted as systemwide. By default, resource names are qualified by the user identification code (UIC) group number of the creating process." And "To queue a lock on a systemwide resource, the calling process must either have SYSLCK privilege or be executing in executive or kernel mode."
System-wide locks are not qualified by UIC, and can and do continue to exist past the exit of a process. Non-system locks are constrained within the UIC group, and get cleaned up when the process(es) that have an interest in the lock resource exit.
To misuse this, folks would have to code to use the privilege, and create bogus locks. This could conflict with other locks (but that can already happen, even without SYSLCK) and this could also cause resource starvation if numbers of bogus locks get queued and not released. Could users misuse this? Sure. The results? The potential for resource starvation. But then users can also consume other resources, such as disk space. And that's a whole lot easier to consume.
Stuff that needs SYSLCK does need to clean up locks, but if your present environment is doing that and is working more or less as expected, then running with SYSLCK or installing with SYSLCK matters not; the code is already cleaning up its locks as appropriate.
Background on lock management on OpenVMS:
http://labs.hoffmanlabs.com/node/492
Was I in your senior management chain, I'd be considering a request for a private conversation with whomever is driving this discussion, too. That would be an interesting conversation. Was I particularly cranky or was the justification behind this whole SYSLCK discussion thread somewhat sketchy, I'd also be asking some pointed questions around focus and goals and (not-lock-related) resources and around the use and plans for translated code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 12:32 PM
тАО04-26-2010 12:32 PM
Re: SYSLCK privileges - What are the dangers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 01:42 PM
тАО04-26-2010 01:42 PM
Re: SYSLCK privileges - What are the dangers
Quotas, limits and privileges protect you against accidental or malicious resource consumption. In a trusted, debugged environment, they are superfluous.
SYSLCK allows the queueing of a persistent lock, which consumes non-paged memory. The lock survives process rundown, so, as long as it isn't dequeued, the allocation is permanent. In its simplest form, the risk is a malicious user who writes a program which allocates many locks, thereby consuming enough memory to adversely effect the system. On recent versions of OpenVMS (~V7), you can see Lock Manager Dynamic Memory in the output of SHOW MEMORY. On older versions it was included in the general NPAGEDYN.
Locks are tiny. On modern systems NPAGEDYN is huge. I'd have to experiment to see what such an attack would look like, but my gut feeling is any half vigilant system manager would see it coming. Even a tight loop requesting locks would take quite some time to consume enough memory to cause any significant problems, so there'd be an obvious CPU bound looping process to investigate.
I agree with Hoff, that in this instance it's probably safe to grant SYSLCK privilege to known, trusted users running a known and debugged program (which, by definition, you already believe is safe with SYSLCK because you're happy to INSTALL it with SYSLCK).
If you want to keep the parinoids happy, sample "Lock Manager Dyn Memory" on a regular basis. On a stable system "Total" should be static, and "Free" will vary with load. Sound an alarm if you see the total increase (means there's been an expansion) and increase the sample rate, watching free space more closely.
Going a bit further, write a lock gobbler process yourself and time how long it takes to eat 1MB of memory so you can work out how long it would take to cause you trouble.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 02:58 PM
тАО04-26-2010 02:58 PM
Re: SYSLCK privileges - What are the dangers
Just curious but what goes wrong when you try to install with SYSLCK priv?
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 04:10 PM
тАО04-26-2010 04:10 PM
Re: SYSLCK privileges - What are the dangers
Richard, see
https://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1422114
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 09:11 PM
тАО04-26-2010 09:11 PM
Re: SYSLCK privileges - What are the dangers
There have been a few comments in this thread stating that SYSLCK allows "persistent" locks to be created. These comments are confusing "system owned locks" with "locks with system wide name scope".
SYSLCK privilege has nothing to do with the ability to create system owned locks (that requires being called from exec or kernel mode). System owned locks are created by using the "reserved by Digital (now HP)" LCK$M_CVTSYS flag. System OWNED locks must be manually cleaned up, as the RSB (Resource Block) will not be removed when the last lock is dequeued.
See http://h71000.www7.hp.com/doc/83final/4527/4527pro_045.html for a description of the flags.
SYSLCK allows the use of the LCK$M_SYSTEM flag, and this causes the newly created lock to be in the system resource domain.
SYSLCK doesn't in itself allow a user to consume any more resources; the risk is resource name collision with other processes in the cluster.
See http://h71000.www7.hp.com/doc/82final/5841/5841pro_022.html#147_resourcenames for a description of what constitutes a unique resource.
The following is a slightly edited extract:
-----------------------
7.2.3 Resource Names
The lock management system services refer to each resource by a name composed of the following four parts:
A name specified by the caller
The access mode (KESU); determined by the caller's access mode unless a less privileged mode is specified in the call to the SYS$ENQ
The resource domain (based on parent lock, or if a new root lock, the LCK$M_SYSTEM flag or the optional rsdm_id parameter. Default is callers UIC group)
The identification of the lock's parent (optional)
For two resources to be considered the same, these four parts must be identical for each resource.
-----------------------
SYSLCK allows the holder to create/hold resource names in the system (Cluster) wide name space. So it is therefore possible for a user to write a program that will interfere with other users of specific resource names with the same access mode that are in the system resource domain.
This is mitigated somewhat by the fact that the scope of resource names is also dependent on the access mode. So if a user does not have at least cmexec priv, then what they can interfere with is limited to user mode locks.
The XQP and RMS use kernel and exec mode locks, so these locks couldn't be affected by a $ENQ from process with only SYSLCK priv.
As Hoff stated, a process could create many resource names and consume non-paged pool, but that is true when the scope is system or UIC group, so SYSLCK really isn't significant as far as resource consumption is concerned.
A malicious user could affect whatever RS/1 is using locks for (my guess is it may be using locks to implement concurrent use "licensing" enforcement). If that is the case, it is possible for a user to make RS/1 think all concurrent licenses are in use, even though no one is using RS/1.
I agree with Hoff, a process with SYSLCK, TMPMBX, and NETMBX isn't a big risk.
SYSLCK priv does not allow the holder to queue EXEC mode locks in the same fashion that SYSNAM allows the holder to create EXEC mode logical names.
Jon
Also see:
http://www.decuslib.com/decus/vmslt99b/tmesis/lock-owned-by-proc-q.txt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-26-2010 09:17 PM
тАО04-26-2010 09:17 PM
Re: SYSLCK privileges - What are the dangers
The SYSLCK privilege lets the user's process lock systemwide resources with the Enqueue Lock Request ($ENQ) system service or obtain information about a system resource with the Get Lock Information ($GETLKI) system service.
Grant this privilege to users who need to run programs that lock resources in the systemwide resource namespace. However, exercise caution when granting this privilege. Users who hold the SYSLCK privilege can interfere with the synchronization of all system and user software.
Please refer page 289 from OpenVMS Guide to System Security
http://h71000.www7.hp.com/doc/732final/aa-q2hlg-te/aa-q2hlg-te.pdf
Regards,
Ketan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-27-2010 12:24 AM
тАО04-27-2010 12:24 AM
Re: SYSLCK privileges - What are the dangers
I wondered what system software uses usermode locks with system scope?
After looking at the output of
SDA> show locks
on an Alpha 8.3 system, it does appear there are usermode (!!!) locks with system scope being used by some important software. Even the AUDIT_SERVER is using user mode locks. Why?
So there may actually be more potential risk than previously stated to handing out SYSLCK, at least to processes that have the ability to run abitrary programs.
Jon