Sorry for the late and somewhat lengthy reply. It was back in the second half of the 90s when I was in IBM education that we tried to understand "daemon procesing". I thought I understand how "daemon processing", BPX.DAEMON and prorgram controlled interact. However, Barbara's post about her problems with FTP showed me, I was missing something, or, that something has changed since then.
I've been working through my old material and the elder an newer manuals. The net result being, that I seem to have understood "daemon processing" correctly: A program changing the userid & uid of the current process *without* knowing the target user's password needs to run with (e)uid=0, must have READ access to BPX.DAEMON and all load modules in the address space must have been loaded from program controlled libraries (or have the program controlled extended attribute set, if loaded from the file system. For brevity, I'll only talk about controlled libraries hereafter). What I didn't realize, and never stumbled across, was the exact requirement when a program changes the userid & uid of the current process while *knowing* the target user's password. I knew from experience that no access to BPX.DAEMON is required (this knowledge lead to my, a bit unluckily formulated, initial response). What I didn't know was that still all load module must come from program controlled libraries. It seems I just never stumbled across this case. The documentation on BPX.DAEMON in the z/OS UNIX Planning Guide is a bit unclear in this respect (the OS/390 V1.2 book was much fuzzier than the description as of OS/390 V2.10). I interpreted it to say that neither BPX.DAEMON authority nor program controlled is required when the password is known. This is seemed to match with my experience, however, it is not correct. The description of the __passwd() library call (as of OS/390 V1.2) clearly states: "If the BPX.DAEMON facility class profile is defined, then all modules within the address space must be loaded from a controlled library. This includes all modules in the application and run-time libraries." So, to be able to change identity with the password at hand when BPX.DAEMON *is* defined, you don't need access to BPX.DAEMON, but still all load modules must have been loaded from a program controlled library. During this research, I also found the reason why so often a requirement for access to BPX.DAEMON is described when it is not actually needed: In an elder C/C++ Runtime Library Reference (MVS/ESA V5), is says: "The caller of this service must be a member of the BPX.DAEMON facility class profile." I can't say whether the above statement was wrong or whether the program controlled requirement was not yet in place at that time. But it clearly lead to the statement on "BPX.DAEMON access required". I guess for a long time, the statement should have read "all load modules must reside in program controlled libraries." Please accept my apologies for the confusion my posts in ignorance may have caused. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
