>Besides fixing up pads, here are some of the permissions on my system >to BPX.DAEMON I see that should apply to your system when you try to add >it back, there are others here that wouldn't apply to a generic system. > >USER ACCESS >---- ------ >FTP READ >IMWEBSRV READ >OMVSKERN READ >REXEC READ >RSHD READ >OREXECD READ >BPXOINIT READ >LDAPSRV READ >stc_grp READ (this is a group that all STCs are connected to)
This list has some entries that are not needed. There really are only a few processes that need READ access to BPX.DAEMON: - cron - rlogind - rshd - uucpd So the MVS userids that those processes are being run under need READ. - Neither FTP, nor HTTPD (IMWEBSRV), nor LDAP, nor "all other STC's" need it. - STC OMVS is usually defined trusted, so it would implicitly have READ, even though it does not need it (it's not a process!) - BPXOINIT does not need it by itself, but will need it *if* any processes started from /etc/rc (running under BPXOINIT's userid) will need it. - inetd may need it if any process it start may need it (e.g. rlogind) 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). On UNIX systems, a process running with uid=0 has the highest privileges in the system, so why should it not be able to *decrease* its current privileges by switching from uid=0 to uid<>0? On UNIX systems, there simply is no reason not to allow this. The same would also apply to z/OS UNIX if privileges were only controlled by the uid. But on z/OS, each process also as a userid besides the uid. And while changing the uid from 0 to non-zero does indeed decrease privileges, changing the *userid* may well increase privileges. This is not what you want any and all uid=0 processes to be able to do. You want to limit this possibility to certain *userids*. 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. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
