RE: chmod 444 /etc/shadow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Have you run strace to see what it is doing when it reports the error?


Hattie Rouge

> -----Original Message-----
> From: pam-list-admin@xxxxxxxxxx 
> [mailto:pam-list-admin@xxxxxxxxxx] On Behalf Of ahoward
> Sent: Monday, May 19, 2003 2:23 PM
> To: pam-list@xxxxxxxxxx
> Subject: Re: chmod 444 /etc/shadow
> 
> 
> 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
> 


_______________________________________________

Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list

[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux