> - Neither FTP, nor HTTPD (IMWEBSRV), nor LDAP, nor "all other STC's" need it. I beg to differ. FTP most certainly did not run until I had deleted the bpx.daemon profile from facility. The reason was the unclean environment (pads)
In my case, OMVS is running under OMVSUS1, which is trusted with uid(0). FTPD and BPXAS run under OMVSUS2, which is a 'normal' OMVS userid with UID(0). That is the reason I had to activate bpx.shared. > What is being protected with BPX.DAEMON is the ability for any process > running with uid=0 to change that process' userid to any other userid > *without* knowing the target user's password. This is what is being called > "daemon processing" in this context. Neither FTP nor HTTPD nor LDAP not > (probably) "all other STCs" do a userid change *without* knowing the > password. They all *do know* password of the target userid (e.g FTP prompts > the user). That was the part that I did not get at all: I had typed in my password and *then* it went south. Why would bpx.daemon processing even come into play here? ftp worked again the second I had deleted the bpx.daemon profile. Admittedly, OMVSUS2 (that it was running under) does not have the priviledges of my TSO userid in z/OS terms (different group with ALTER access to a lot more dataset profiles than the STCs, which generally only have READ to those profiles), but it does have more priviledges in OMVS terms. After all, my OMVS segment is defined via AUTOUID/AUTOGID, and when I access the shell, I am told my EUID is 5001. I do have access to BPX.SUPERUSER. > If BPX.DAEMON is *not* defined at all, z/OS UNIX behaves like any other UNIX. > If BPX.DAEMON is defined, a process that wants to change uid/userid without > knowing the password must: > a) be running with uid=0 > b) be running with a userid that has READ to BPX.DAEMON > c) be running in a clean address space, in other words, any and all load > module loaded into the AS must come from a program controlled library or, in > case of being loaded from the file system, must have the program controlled > extended attribute set. I don't think that is true for the case of RDz (yes, an IBM product). On my system BPX.DAEMON is currently NOT defined, and RSED terminated itself (trying to change userids, in this case using bpxoinit to start with - ftpd used a bpxas) with no message other than something completely misleading. It turned out the real reason it terminated was the same dirty environment that caused me problems with ftpd - DFSMRCL0 was not in WHEN(PROGRAM). Once I defined that, RSED came up. Given the wording in the installation instructions, I think that RSED is using some dirty mechanisms to do what it does with the userid change. This is why I hate USS: It is just so inconsistent and I cannot rely on the books to tell me the whole truth. Or I am too dumb to read the books correctly. Who wants to be reminded one is dumb? Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
