Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686

From: ahoward <ahoward(at)fsl(dot)noaa(dot)gov>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686
Date: 2003-05-17 19:33:54
Message-ID: Pine.LNX.4.53.0305171931240.4785@eli.fsl.noaa.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)fsl(dot)noaa(dot)gov> wrote in message news:<Pine(dot)LNX(dot)4(dot)53(dot)0305162007060(dot)4785(at)eli(dot)fsl(dot)noaa(dot)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(dot)t(dot)howard(at)fsl(dot)noaa(dot)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(dot)t(dot)howard(at)fsl(dot)noaa(dot)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(dot)t(dot)howard(at)fsl(dot)noaa(dot)gov
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Darko Prenosil 2003-05-17 20:22:51 Re: Executing External Programs
Previous Message Tor Løjborg 2003-05-17 19:08:38 Re: Executing External Programs