On Mon, 19 May 2003, Gary Algier wrote:
> I just tested some of this on my linux system:
> root@xxxxxx 64% ls -l /etc/shadow
> -r--r----- 1 root shadow 1364 May 13 14:16 /etc/shadow
> root@xxxxxx 65% grep shadow /etc/group
> shadow:x:11:postgres
> root@xxxxxx 66% su postgres -c id
> uid=26(postgres) gid=26(postgres) groups=26(postgres),11(shadow)
> root@xxxxxx 67% su postgres -c "grep games /etc/shadow"
> games:*:12160:0:99999:7:::
>
> As you can see a process started with "su postgres -c ..." _can_ read the shadow
> file (with appropriate modes, ownership, etc.). So unless the postgres process
> goes out of its way to do a "setgroups()" system call it _has_to_ work.
you are quite right - i get the same on my system.
i'm at a loss. i've tried all manner of things and nothing seems to work
except 0444. the error is always as
May 19 21:02:15 omega postgresql(pam_unix)[26716]: auth could not identify password for [ahoward]
May 19 21:02:17 omega postgresql(pam_unix)[26717]: authentication failure; logname= uid=26 euid=26 tty= ruser= rhost= user=ahoward
i really don't think this is a problem with pam, but with postgresql. there
numerous posts about this with no resolutions. as far i know i am the only
one who actually got it 'working' - albeit unsafely. i glimpsed the postgres
source for setgrp() and found nothing, but still feel the problem must be
here.
* postgressql runs as postgres
[root@xxxxx dsg]# ps -elf | grep post
000 S postgres 11800 1 0 75 0 - 1434 schedu 17:28 pts/0 00:00:00 /usr/local/pgsql/bin/postmaster -i
040 S postgres 11802 11800 0 75 0 - 1682 schedu 17:28 pts/0 00:00:00 postgres: stats buffer process
040 S postgres 11803 11802 0 75 0 - 1443 schedu 17:28 pts/0 00:00:00 postgres: stats collector process
* postgresql is run using 'su -c'
[root@xxxxx dsg]# grep 'su' /usr/local/pgsql/bin/pg_init
# This is an example of a start/stop script for SysV-style init, such
su - $PGUSER -c "$DAEMON start -D '$PGDATA' -s -l $PGLOG $PGOPT"
su - $PGUSER -c "$DAEMON stop -D '$PGDATA' -s -m fast"
su - $PGUSER -c "$DAEMON restart -D '$PGDATA' -s -m fast $PGOPT"
su - $PGUSER -c "$DAEMON status -D '$PGDATA'"
* postgresql is configured for pam
[root@xxxxx dsg]# grep -v '^#' /usr/local/pgsql/data/pg_hba.conf | grep pam
host all all 137.75.0.0 255.255.0.0 pam
* pam.d file seems correct (pam.d/postgresql is used by default)
[root@xxxxx dsg]# cat /etc/pam.d/postgresql
#%PAM-1.0
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
* shadow group exists and postgres is in it
[root@xxxxx dsg]# grep shadow /etc/group
shadow:x:4002:root,postgres
* postgres can read /etc/shadow
[root@xxxxx dsg]# su postgres -c 'grep games /etc/shadow'
games:*:11942:0:99999:7:::
* /etc/shadow has group shadow read perms
[root@xxxxx dsg]# ls -l /etc/shadow
-r--r----- 1 root shadow 2526 May 8 20:09 /etc/shadow
but all attempts to login fail with the error above? i even tried making
/etc/shadow group postgres and group $user and that also didn't work... my
conclusion is that postgresql does something funny with the gid/pam combo
which thwarts these attempts... i'm at a loss.
-a
>
>
> --
> Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758
> Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
>
>
> _______________________________________________
>
> Pam-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/pam-list
>
--
====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ara.t.howard@xxxxxxxxxxxx
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================
_______________________________________________
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
