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

SYSLCK privileges - What are the dangers

 
SOLVED
Go to solution
Joe Gadsby
Advisor

SYSLCK privileges - What are the dangers

Hi

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-
11 REPLIES 11
Joe Gadsby
Advisor

Re: SYSLCK privileges - What are the dangers

"The 2-3 lines of the manual are too enlightening."

areN'T

ftfm

-jg-
Hoff
Honored Contributor
Solution

Re: SYSLCK privileges - What are the dangers

This question is a reprise of or a continuation of:

http://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.
Hoff
Honored Contributor

Re: SYSLCK privileges - What are the dangers

And as I stated in the other thread... Would I pass SYSLCK out over on the "Deathrow" cluster? Probably not. Why? Because somebody on that cluster is going to queue a gazillion of these locks and blow out a resource, either due to a run-away program or due to a failure to clean up system locks on exit, or just for giggles. But for a handful of trusted and authenticated local users? SYSLCK is not a particular concern. Pass it out. Your management chain has some much bigger questions to consider and to address as compared with this comparatively inconsequential SYSLCK discussion.
John Gillings
Honored Contributor

Re: SYSLCK privileges - What are the dangers

Joe,

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.
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: SYSLCK privileges - What are the dangers

Hi Joe,

Just curious but what goes wrong when you try to install with SYSLCK priv?

Cheers Richard Maher
John Gillings
Honored Contributor

Re: SYSLCK privileges - What are the dangers

>Just curious but what goes wrong

Richard, see

https://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1422114
A crucible of informative mistakes
Jon Pinkley
Honored Contributor

Re: SYSLCK privileges - What are the dangers

Joe,

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
it depends
Shriniketan Bhagwat
Trusted Contributor

Re: SYSLCK privileges - What are the dangers

Hi,
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
Jon Pinkley
Honored Contributor

Re: SYSLCK privileges - What are the dangers

Yes, the manual says "Users who hold the SYSLCK privilege can interfere with the synchronization of all system and user software."

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
it depends
Richard J Maher
Trusted Contributor

Re: SYSLCK privileges - What are the dangers

John,

Oh, I see. Hard to see what options Joe has besides give them SYSLCK.

Jon,

Great explanation.

Joe,

I'd be more worried about not having the source-code! Good luck

Cheers Richard
Joe Gadsby
Advisor

Re: SYSLCK privileges - What are the dangers

I gave SYSLCK to the users that required it.