Re: System value - Share Memory Control (QSHRMEMCTL)

[Tim Bronski <tim.bronski@xxxxxxxxx>]

IIRC, JDE used to make some use of shared memory.

On 1/7/2014 6:06 PM, Dan Kimmel wrote:
> 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.