Really don't know why I bothered opening up a PMR. Per IBM, CRTLIB and DLTLIB are shipped with *PUBLIC *USE and we need to restore that in order to use the IFS functionality.

I really, really didn't appreciate being told that there was no way around IBM object authority. Really. So apparently when I sign in *I* have rights to run system state programs to validate the password? So whenever I run STRTCPSVR I have direct rights to every underlying program that runs? Or is it just possible that I can have access to STRTCPSVR and STRTCPSVR calls a system state program with more authority than I have? It isn't possible that this functionality is implemented in a very poor way and they don't want to pass control to a program/process that runs with adopted authority?

OK, moving on to something I can actually work with.




-----Original Message-----
From: Andrew Lopez (SXS US)
Sent: Friday, February 05, 2021 8:57 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: RE: Question on ACS and working with the IFS....

Honestly I would find most shops do not secure out the usage of commands like CRTLIB. Instead they remove the command line authority and rely upon the user being restricted to programs which use that command. Here I consider the program IBM uses in iACS just such a program.

We're pretty well covered there. Both CRTLIB and MD are *PUBLIC *EXCLUDE on our system (as are all but 2 libraries). Not many directories just below root aren't locked down.

I'll open a PMR for this. If the user has access to the original IFS object and write access to the destination directory, it's the system's problem to copy the file over. I wouldn't understand why they didn't leverage QSH/QSHELL/whatever to do the copy instead of this.
_____________________________________________________________________
Spirax-Sarco Engineering Plc. This e-mail has been scanned for viruses by Cisco Cloud Email Security.


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.