RE: System value - Share Memory Control (QSHRMEMCTL)

You're not going to see the shared memory api's used very much in applications that were written for IBMi. So I don't think there should be any impact at all in preventing a user from writing to shared memory.

Shared memory is a tool for parallel programming in Unix. The api's in question are POSIX standard so IBMi supports them. They really aren't needed in IBMi programming as any IBMi job can share memory it has allocated with any other job by passing the abstracted (Single Level Storage) pointer. The architecture behind Unix has no abstracted pointers, only absolute offsets within the program that the operating system combines with a base pointer it keeps for each job to the real address of the memory. A *nix program must ask the operating system to allocate a shared memory segment and must do all work on that segment using an offset pointer given it by the OS.

All this system value does is restrict the users who can WRITE in a shared memory segment allocated in the above manner. It does not restrict which users can create a memory segment or who can read a memory segment. The user who creates the segment owns it and can always write to it. Most parallel jobs using shared memory have a "server" who owns the segment and "clients" who read what's there. That scenario would not be affected. There are models where several users attach and write in the segment. These operations must be protected by semaphores or some other method to prevent concurrent writes on out-of-date segments. The OS provides the semaphores for use by the programmer, but no inherent protection against concurrent writes in a multiprocessor environment.

If it was me, I'd turn on the system value in a test partition and run through my application test suite to see if anything breaks.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Tuesday, January 07, 2014 10:13 AM
To: 'Midrange Systems Technical Discussion'
Subject: System value - Share Memory Control (QSHRMEMCTL)

Security audit is requesting we change this from 1 (share) to 0 (cannot share).
Has anyone dealt with this, notice any performance hits when setting to 0.
The Share Memory Control (QSHRMEMCTL) system value defines which
users are allowed to use shared memory or mapped memory that has write
capability.
Your environment may contain applications, each running different jobs, but
sharing pointers within these applications. Using these APIs provides for
better application performance and streamlines the application development
by allowing shared memory and stream files among these different
applications and jobs. However, use of these APIs might potentially pose a
risk to your system and assets. A programmer can have write access and can
add, change, and delete entries in the shared memory or stream file.
To change this system value, users must have *ALLOBJ and *SECADM special
authorities. A change to this system value takes effect immediately.
Note: This system value is a restricted value. See Security system
values<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarl/rzarlsy
sval.htm#rzarlsysval> for details on how to restrict changes to security
system values and a complete list of the restricted system values.
Table 1. Possible values for the QSHRMEMCTL system value:

0

Users cannot use shared memory, or use mapped memory that has write
capability.
This value means that users cannot use shared-memory APIs (for example,
shmat() - Shared Memory Attach API), and cannot use mapped memory
objects that have write capability (for example, mmap() - Memory Map a File
API provides this function).
Use this value in environments with higher security requirements.

1

Users can use shared memory or mapped memory that has write capability.
This value means that users can use shared-memory APIs (for example,
shmat() - Shared Memory Attach API), and can use mapped memory objects
that have write capability (for example, mmap() - Memory Map a File API
provides this function).



Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx>
http://www.pencor.com/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.