>>Neither FTP, nor HTTPD (IMWEBSRV), nor LDAP, nor "all other STC's" need it. > >I'm not the RACF admin, but I'm sure some of those permissions in the list >I provided came from vendor documentation.
I know that, unfortunately, many products document they need BPX.DAEMON despite the fact they don't need it. This has been discussed more than once in the last 15+ years (probably more on MVS-OE than here). I often submit RCFs if I find documentation is in error or unclear. I admit I didn't do it for the BPX.DAEMON thing. >Regarding your command that "all other STCs" don't need it", that can be >true of just about any permission given to a group. It is just good >practice from a RACF admin standpoint to permit to groups instead of >individual userids most of the time. I agree. I didn't mean to talk against that practice. > In this case, STCs are trusted, >so I don't see a problem with the blanket permission that may prevent >me from having to get a specific permission in the future. I'm more restrictive in granting permissions that your shop seems to be. I do not grant the trusted attribute to any and all STC. But if you do, then you're of course right that granting READ to BPX.DAEMON to "all other STCs" doesn't make it "worse". >If you are implying that your list is the only thing on z/OS to ever >need BPX.DAEMON, you are looking at this only from an IBM >standpoint and not from anything home grown or from >other vendors. I'm looking at it with the information I collected during the past 15+ years. I admit that this is not a completed representation of all products out there, for sure not any home grown application. The latter probably haven't been discussed publicly. But, you probably also have accurate documentation for those. Those who programmed that stuff understand if the software is doing "daemon processing" or not. You can test any software for the BPX.DAEMON requirement easily (on a test system). If the software is running fine with READ on BPX.DAEMON, revoke the right and see if it continues to do its job. If it does, BPX.DAMOEN is not needed. >For example, the STC group in the list I >provided is connected the the CA-MSM tomcat web server, >which requires BPX,DAEMON access. There could be >other IBM software also. Does WebSphere Application Server >require it? If so, that would the other reason "stc group" was >in the list. My client has a very heavy WAS on z/OS environment. Do any of these products change the userid of its processes (not threads) without knowing the password? Then they need access to BPX.DAEMON. If not, they don't. IBMs HTTPD (the on base on Domino Go Web Server) starts threads to handle work under different userids. It needs access to BPX.SERVER, IIRC without looking into the book. I'm sure I've been running FTP without access to BPX.DAEMON. I pretty sure I've been running HTTPD without access to BPX.DAEMON. Unfortunately (for this discussion), I'm not longer doing a sysprog job and thus don't have access to a test system to play with. In addition, we're an ACF2 job, and things are a bit different in ACF2 sometimes. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
