Red Hat Bugzilla – Bug 177132
rhdb fails to start/stop when certain pam modules are enabled
Last modified: 2015-01-07 19:11:23 EST
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: 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
Everytime, if you install pam_access and allow the user postgres in
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
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
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
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.