Description of problem: In /etc/rc.d/init.d/rhdb, the commands to start and stop the database postmaster job redirect input from /dev/null when executing the commands via "su". This will cause the startup and shutdown to fail (with no log of it since the output and error are also redirected to /dev/null) if the system is configured with certain pam modules which require a tty parameter. For example, if the system uses pam_access, the su will fail with the error "su: incorrect password" as the pam_access will fail with "pam_access[9831]: couldn't get the tty name". Version-Release number of selected component (if applicable): rh-postgresql-server-7.3.10-1 on RHEL 3.x How reproducible: Everytime, if you install pam_access and allow the user postgres in /etc/security/access.conf. Steps to Reproduce: 1. Configure /etc/security/access.conf to allow logins for postgres and any other desired users. 2. Modify /etc/pam.d/system-auth to include the line: account required /lib/security/pam_access.so 3. Try to start/stop the db via /etc/rc.d/init.d/rhdb Actual results: rhdb fails Expected results: rhdb works Additional info: While the supplied rhdb script will work on the default setup, there are many pam modules (included in the distribution) which if enabled will cause this problem.
BTW, I "fixed" this on my system by commenting out the redirection to /dev/null for the input on the su commands... Now works for me fine. Not sure why the redirect is there, but it certainly works for me without it.
Why is pam invoked at all during "su" from root to another ID? I should think that that breaks a ton of stuff besides Postgres ... The reason for the redirect is exactly to make sure that the postmaster process isn't associated with any specific tty --- else it could be killed by typing control-C on the tty, which you probably don't want. (I'm not sure if that's true on RHEL3 in particular, but there definitely are Unixen where it would be true.)
The RHEL distribution contains a /etc/pam.d/su file which by default acts this way. Why? Don't know; I'm not Red Hat nor the pam authors, etc. I understand associating it with a tty can cause various "problems" of sort. But I think the pam issue is potentially more serious. I'll leave Red Hat to decide which is more serious, or how to resolve the conflicts. One could question if this isn't really a bug in the pam modules, in that they should fail more gracefully if there is no tty available? I'm not qualified to rule on that issue though.
Yeah, I think it's a pam issue as well. Reassigning ...
PAM package with fixed pam_access was released in RHEL3U7 Beta.
Errata containing fixed pam_access was released.