su, postgres, and pam [SOLVED]

Message

Pasketti · Post by **Pasketti** » Sat Jul 09, 2005 2:54 pm

On my last emerge -u, both postgresql and pam got updated. No biggie.

But now when I try to start or stop postgresql, I get this:
su: Authentication service cannot retrieve authentication info.

The postgresql script in /etc/init.d has a few lines in it like this:
su - $PGUSER -c "/usr/bin/pg_ctl start -D '$PGDATA' -s -l '$PGLOG' -o '

which I think is where the problem lies. That script didn't change in the upgrade - I checked the dispatch-conf archive to be sure - so it has to be something in pam. I'm thinking that during the pam upgrade, something in one of the pam files got changed to where it isn't working like it used to.

Unfortunately, my pam-fu is weak. I pity me.

I checked the config files in /etc/pam.d, but nothing stands out other than the removal of the library paths.

I can su to root just fine.

Any ideas?

new /etc/pam.d/su:

Code: Select all

auth       sufficient   pam_rootok.so
auth       required     pam_wheel.so use_uid
auth       include              system-auth
account    include              system-auth
password   include              system-auth
session    include              system-auth
session    required     pam_env.so
session    optional             pam_xauth.so

new /etc/pam.d/system-auth:

Code: Select all

auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth nullok
auth       required     pam_deny.so
account    required     pam_unix.so
password   required     pam_cracklib.so retry=3
password   sufficient   pam_unix.so nullok md5 shadow use_authtok
password   required     pam_deny.so
session    required     pam_limits.so
session    required     pam_unix.so

old /etc/pam.d/su:

Code: Select all

auth       sufficient   /lib/security/pam_rootok.so
auth       required     /lib/security/pam_wheel.so use_uid
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_env.so
session    optional     /lib/security/pam_xauth.so

old /etc/pam.d/system-auth:

Code: Select all

auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_unix.so likeauth nullok
auth       required     /lib/security/pam_deny.so
account    required     /lib/security/pam_unix.so
password   required     /lib/security/pam_cracklib.so retry=3
password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok
password   required     /lib/security/pam_deny.so
session    required     /lib/security/pam_limits.so
session    required     /lib/security/pam_unix.so

Pasketti · Post by **Pasketti** » Sat Jul 09, 2005 6:29 pm

The problem turned out to be a missing entry for user "postgres" in /etc/shadow.

I added a passwordless entry for user postgres, and the error went away.

Pasketti · Post by **Pasketti** » Sat Jul 09, 2005 6:41 pm

I just remembered that shadow also got updated.

No idea if that caused the problem or not, but I ran pwconv to recreate /etc/shadow just in case entries were needed for the other service accounts.

shugaa · Post by **shugaa** » Mon Jul 11, 2005 7:41 pm

Thanks for sharing. Had the same problem and your advice solved it for me, too.

lkraav · Post by **lkraav** » Wed Jul 13, 2005 2:04 pm

you guys rock, it worked.

NightMonkey · Post by **NightMonkey** » Fri Jul 15, 2005 8:31 am

Pasketti wrote:The problem turned out to be a missing entry for user "postgres" in /etc/shadow.

I added a passwordless entry for user postgres, and the error went away.

This is really strange. It appears that on two of my boxes, /etc/shadow (timestamp Jun 9 11:21 PDT on one, and Jul 5 14:30 PDT on another) got severely truncated. Many users, especially daemon users, got zapped, like cron, apache, etc. Genlop doesn't report anything merging at that exact time, but the shadow package had been updatedand I haven't modified that file myself in many months.

Really odd. The solution here (pwconv) appears to have fixed the problem, but it is worrysome to have this file just get "wonky" all of a sudden.

Anyone have similar behavior?

converter · Post by **converter** » Wed Jul 20, 2005 5:14 pm

NightMonkey wrote:
Pasketti wrote:The problem turned out to be a missing entry for user "postgres" in /etc/shadow.

I added a passwordless entry for user postgres, and the error went away.
This is really strange. It appears that on two of my boxes, /etc/shadow (timestamp Jun 9 11:21 PDT on one, and Jul 5 14:30 PDT on another) got severely truncated. Many users, especially daemon users, got zapped, like cron, apache, etc. Genlop doesn't report anything merging at that exact time, but the shadow package had been updatedand I haven't modified that file myself in many months.

Really odd. The solution here (pwconv) appears to have fixed the problem, but it is worrysome to have this file just get "wonky" all of a sudden. Anyone have similar behavior?

Thanks to this particular postgres issue, I just noticed that my shadow file hadn't been updated in a long while, so it's probably an issue with the shadow package. I'd bet that there was a nice little "you must do this after updating shadow" message after an upgrade a while back and we both missed it.

sirber · Post by **sirber** » Fri Aug 05, 2005 8:05 pm

worked for me! thanks!

funeagle · Post by **funeagle** » Thu Nov 17, 2005 4:48 pm

Worked for me too ! thanx!

allan · Post by **allan** » Thu Jun 15, 2006 1:38 am

Thanks for the hint about /etc/shadow being out of sync. Both apache and postgresql startups were complaining for me.

BTW - The program 'pwconv' will resync /etc/shadow for you. No need to edit by hand.

kiksen · Post by **kiksen** » Mon Jul 03, 2006 11:02 am

Thanks... pwconv did the trick.