Initial ASP group is the IASP you are placed into. In this respect it's easiest to think of it as mounting a drive, or setting a database context - works very much the same way.
Normally, the answer about crossing IASP's would be no. The IASP's are completely distinct - that's why you can have the same library names in each. When in an IASP you can only see objects in*SYSBAS and the libraries in that IASP. I'm referring to a command such as WRKOBJ *ALL/xxxx or CALL xxxx, if the target object is in the other IASP those would fail.
However- one could submit a job and specify the other IASP as the initial IASP group command in the SBMJOB - in which case they could access the other IASP through that job. You could set their profile to be *EXCLUDE on the other IASP *dev object and that would prevent something like a SBMJOB or trickery through the IFS.
There is a command SETASPGRP which allows you to change to another IASP, but again if you exclude the user explicitly that wouldn't work either.
Unless of course they have *ALLOBJ - which is another good reason why *ALLOBJ should rarely be granted.
James P. Wiant
Test System Administrator
FOODSTUFFS
NORTH ISLAND LIMITED
DD: 09 621 0774 | M: 027 463 4159| P: 09 621 0600
DX Box CX 15021 or PO Box 27480 Mount Roskill, Auckland 1440, New Zealand
Fast is fine. Accuracy is everything
Earp, Wyatt
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Aaron Bartell
Sent: Friday, 3 October 2014 10:14 AM
To: Midrange Systems Technical Discussion
Subject: iASP security
Hello,
I have some iASP security questions I hope someone can answer. Let me lay out a scenario:
*Scenario*
- I have a single IBM i instance, let's call this IBMi1
- I have two IASPs configured, IASP1 and IASP2
- I have two users configured, USR1 and USR2 (QSECURITY=30, USRCLS(*PGMR))
- USR1 has a *JOBD with INLASPGRP(IASP1)
- USR2 has a *JOBD with INLASPGRP(IASP2)
- I have two libs, LIB1 is in IASP1 and LIB2 is in IASP2
- I have two RPG *PGM objects, RPG1 is in LIB1 and RPG2 is in LIB2
When USR1 logs into a IBMi1 5250 session (and inherently placed in IASP1), can they see or attempt to invoke LIB2/RPG2 in IASP2 if the authority is *PUBLIC(*USE)?
Can USR1 see or invoke IFS files in IASP2 if files are set to chmod go+rx?
I would test this myself except I am having issues setting up the scenario on IBM's PDP <
https://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/stg_com_sys_power-development-platform>
service
(I have an email into support). I would try iASP on the variety of other servers I have access to, but I don't want to accidentally hose anything :-P
Thanks,
Aaron Bartell
--
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.
######################################################################
This message was scanned for compliance with Foodstuffs North Island Limited email policies
######################################################################
This message has been sent from Foodstuffs North Island Limited (Foodstuffs).
The information contained in this message (including its attachments) is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged material.
If you received this message in error, please contact the sender immediately by return email and delete this message and your reply.
You must not use, disclose, distribute, print or copy any part of this message.
The views and opinions expressed in this message may be those of the individual sender and not necessarily those of Foodstuffs,
in which case the views are not given or endorsed by Foodstuffs.
Please note that this communication does not designate an
information system for the purposes of the Electronic
Transactions Act 2002.
midrange.com
