|
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-----share).
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
Has anyone dealt with this, notice any performance hits when setting to0.
The Share Memory Control (QSHRMEMCTL) system value defines whichbut
users are allowed to use shared memory or mapped memory that has write
capability.
Your environment may contain applications, each running different jobs,
sharing pointers within these applications. Using these APIs provides fordevelopment
better application performance and streamlines the application
by allowing shared memory and stream files among these differenta
applications and jobs. However, use of these APIs might potentially pose
risk to your system and assets. A programmer can have write access andcan
add, change, and delete entries in the shared memory or stream file.http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarl/rzarlsy
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<
sval.htm#rzarlsysval> for details on how to restrict changes to securityFile
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
API provides this function).list
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
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.