× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.