Lets NOT assume LNKAUTH=LNKLST! There are good reasons for putting data sets that do not need to APF-authorization into the LNKLST. I would think that now days it would be regarded as a bad practice to specify anything other than LNKAUTH=APFTAB and explicitly APF-authorize only those LNKLST data sets that really should be authorized. A loadlib that is not intended to be authorized might contain modules that would be unsafe to load into an environment running APF-authorized code.
That being said, control of the LNKAUTH parameter, the APF Table, adding data sets to the Link List, and control of the contents of any data set that is APF-authorized must be restricted to Sys Progs that can be trusted and who understand system security issues or your system integrity is non-existent. No MVS Sys Prog worthy of the name would allow any data set to acquire APF status, either by explicit addition to the APF Table or implicitly by addition to LNKLST where LNKAUTH=LNKLST is in effect, without first insuring that update authority to that data set is restricted only to qualified Sys Progs. A corollary to that is that no data set with a HLQ that implies ownership by an individual user or a user group, rather than ownership by the MVS system or by other vendor products maintained by Sys Progs, should EVER be allowed to become APF-authorized, because the DS name could cause a RACF administrator to incorrectly assume it was OK to allow non-SysProgs to have update access. So, an arbitrary USERA who is not a qualified Sys Prog, should never find himself with UPDATE access to a LOADLIB that is APF-authorized. Period! I'm not familiar with Changeman, but if it is a product that allows one to indirectly deploy modules to a LOADLIB to which one lacks direct UPDATE access, that product cannot be configured to permit or enabled to allow any updates to an APF-authorized library to be introduced by a non-SysProg. If there is no way to disable that capability, the product is unsafe. Joel C Ewing On 12/19/2017 01:12 PM, Lizette Koehler wrote: > So, my opinion > > Once a dataset is in the linkst - depending on how it is controlled - someone > could put other code in there that is not system friendly. > > So I have dataset, MYHLQ.USER.LOADLIB in the linklist. > > Now it is apf authorized. > > I use a package like Changemen to deploy to it, but it does not know what > should not go there. I use all valid naming conventions for the process. > But the code could be something "special". > > So USERA decides to create a program with an assembler subroutine that can > filter data in a database and send to an unknown site. > > Or set up other issues in the system. USERA has the authority to deploy to > that dataset. But who is controlling the source to ensure it does not do bad > things. > > > Just my thought > > Lizette > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of R.S. >> Sent: Tuesday, December 19, 2017 6:08 AM >> To: [email protected] >> Subject: Re: Cobol upgrade 6.2 linklist >> >> What is the risk of putting COBOL-compiled code into LINKLIST? >> Let's assume LNKAUTH=LNKLST. >> Such code will not perform any authorized instructions. It can be called from >> another AC=1 code, but the problem is the module, not the COBOL code called. >> What I'm missing? >> >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> >> -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
