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

Started by ahowardalmost 23 years ago5 messagesgeneral
Jump to latest
#1ahoward
ahoward@fsl.noaa.gov

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
====================================

#2ahoward
ahoward@fsl.noaa.gov
In reply to: ahoward (#1)
Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686

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
====================================

#3ahoward
ahoward@fsl.noaa.gov
In reply to: ahoward (#1)
Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686

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
====================================

#4ahoward
ahoward@fsl.noaa.gov
In reply to: ahoward (#3)
Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686

On Sun, 18 May 2003, root wrote:

f

ilia@prohost.org
My Email

Root's sig

huh?

--
====================================
| 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
====================================

#5Noname
kochinc@yahoo.com
In reply to: ahoward (#1)
Re: 7.3.2, pam, on Linux 2.4.18-18.7.x i686

Hi Ara,

Have you got any things from pam-linux mailing list? I am also
interested in their opinions.

Kochin Chang

ahoward <ahoward@fsl.noaa.gov> wrote in message news:<Pine.LNX.4.53.0305171931240.4785@eli.fsl.noaa.gov>...

Show quoted text

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