Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686 - Mailing list pgsql-general

From ahoward
Subject Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686
Date
Msg-id Pine.LNX.4.53.0305171931240.4785@eli.fsl.noaa.gov
Whole thread Raw
In response to 7.3.2, pam, on Linux 2.4.18-18.7.x i686  (ahoward <ahoward@fsl.noaa.gov>)
List pgsql-general
On Sat, 16 May 2003, Kochin Chang wrote:

> Yes, changing permission of /etc/shadow does work, but it realy is NOT
> a 'good thing' as you said.

agreed - though the pam FAQ reccomends it.

>
> In fact, PostgreSQL and pam_unix (or pam_pwdb for that matter) are not
> compatible by design.
>
> PostgreSQL doesn't allow itself to run as root. On RedHat Linux a user
> postgres is used to run the server process. When a client tries to
> connect, it spawns a process, also with postgres's uid, for the
> connection.
>
> Now suppose you have an entry
>
> host   all   all   192.168.24.0   255.255.255.0   pam postgresql
>
> in your pg_hba.conf file, and your /etc/pam.d/postgresql looks like
>
> auth      required   pam_unix.so
> account   required   pam_permit.so
>
> or
>
> auth      required   pam_stack.so service=system-auth
> account   required   pam_permit.so
>
> After received username/password, PostgreSQL uses pam_unix module to
> authenticate the user. What happens with pam_unix is that it sees that
> the calling process's uid is not root, so it calls a helper program
> named unix_chkpwd to verify the password. Unix_chkpwd does a seteuid
> to use the calling process's uid, and then tries to read the password
> info.
>
> Since the process's uid is postgres's uid, the only password info
> allowed to access is postgres's. Accessing any other user's info will
> fail. Therefore the pam_unix reports authenticaion failure unless the
> user happens to be postgres.
>
> The pam_unix's behavior is designed to prevent a user to access other
> users' information. For example, a user entering passwd command can
> only change his/her own password.
>
> Therefore, unless we want to change PostgreSQL to run as root or
> pam_unix to allow access other users' info, those two won't be able to
> work together. Of course, we can create a PAM module to work specific
> for this type of situation.....
>
>
> Kochin Chang

thanks alot for the detailed description - i suspected that to be the case,
but it's good to have confirmed.  it would seem that making a pam module to
handle this case would be preferable to allow postgresql to run as root, since
that would seem to open many root shell exploits...

i've posted a similar email to pam-linux and am waiting for a response from
that group as well.

-a


>
>
> ahoward <ahoward@fsl.noaa.gov> wrote in message news:<Pine.LNX.4.53.0305162007060.4785@eli.fsl.noaa.gov>...
> > On Fri, 16 May 2003, ahoward wrote:
> >
> > well - scoured the new groups and no fixes seem to exist.
> >
> > this works though:
> >
> >   chmod 444 /etc/shadow
> >
> > ;-)
> >
> > i know that's no a 'good thing'.  but how else is a daemon running as user
> > postgres supposed to use a lib which must eventually open /etc/shadow (i some
> > configurations).  does this sound like a bug in pam?
> >
> > -a
> >
> > >
> > >
> > > greetings-
> > >
> > > i've read quite a few posts, but no resolution, to woes people seem to have
> > > setting pam up in pg_hba.conf.
> > >
> > > my problem is as all the rest - it doesn't work, but should.  i'm 100%
> > > confident that i've set things up correctly as i've got pam working on another
> > > linux/pgsql pair (different versions).
> > >
> > > so, before i post another detailed trace of my exact error's/failures i wanted
> > > to see if anyone knows of bugs pertaining to pam or postgresql's interface to
> > > it?  if so, are there patches out there?  has anyone out there gotten pam to
> > > work unsing 7.3.2 on Linux 2.4.18-18.7.x i686?
> > >
> > > thanks in advance for any information.
> > >
> > > regards.
> > >
> > > -a
> > >
> > > --
> > >   ====================================
> > >   | 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@fsl.noaa.gov
> > >   | Phone:  303-497-7238
> > >   | Fax:    303-497-7259
> > >   ====================================
> > >
> >
> > --
> >   ====================================
> >   | 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@fsl.noaa.gov
> >   | Phone:  303-497-7238
> >   | Fax:    303-497-7259
> >   ====================================
>

--
  ====================================
  | 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@fsl.noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  ====================================

pgsql-general by date:

Previous
From: "alex b."
Date:
Subject: query duration
Next
From: James Gregory
Date:
Subject: Re: table inheritance and foreign keys