PAM authentication fails for local UNIX users

Dhanaraj M wrote:

Hi all,

http://archives.postgresql.org/pgsql-admin/2003-02/msg00301.php

I also try to address the same issue..

I run postmaster as postgres user and pg_hba.conf includes the
following entry:

local all dhanaraj pam

However, the authentication fails for this unix local user, whereas it
works for LDAP users.

bash-3.00$ psql -h superdesktop.india.sun.com -U dhanaraj mydb
Password for user dhanaraj:
psql: FATAL: PAM authentication failed for user "dhanaraj"

The following error message that I could see in the server log:
......................
LOG: pam_authenticate failed: Conversation failure
FATAL: PAM authentication failed for user "dhanaraj"
LOG: pam_authenticate failed: No account present for user
FATAL: PAM authentication failed for user "dhanaraj"

The non-root user does not have the permission to read other unix
local user password.
I found two solutions:

1. usermod -K defaultpriv=Basic,file_dac_read postgres

- Gives privilege to read all files. This solution works. Is it the
right way to do?

2. chmod +s processName

- This does not work, because postgres never allows this.

Is there anyother solution to this problem?

Usage questions really don't belong on -hackers - in future please use
-general. Both your proposed solutions are utterly insecure.

See http://itc.musc.edu/wiki/PostgreSQL for some discussion of using
PAM for postgres auth.

cheers

andrew

Andrew Dunstan wrote:

Dhanaraj M wrote:

The non-root user does not have the permission to read other unix
local user password.
I found two solutions:

1. usermod -K defaultpriv=Basic,file_dac_read postgres

- Gives privilege to read all files. This solution works. Is it the
right way to do?

2. chmod +s processName

- This does not work, because postgres never allows this.

Is there anyother solution to this problem?

Usage questions really don't belong on -hackers - in future please use
-general. Both your proposed solutions are utterly insecure.

The problem what Dhanaraj tries to address is how to secure solve problem with
PAM and local user. Other servers (e.g. sshd) allow to run master under root
(with limited privileges) and forked process under normal user. But postgresql
requires start as non-root user. It limits to used common pattern.

There is important question:

Is current requirement to run postgresql under non-root OK? If yes, than we must
update PAM documentation to explain this situation which will never works
secure. Or if we say No, it is stupid limitation (in case when UID 0 says
nothing about user's privileges) then we must start discussion about solution.

See http://itc.musc.edu/wiki/PostgreSQL for some discussion of using
PAM for postgres auth.

It also offer also same insecure solution to add read permission on shadow for
postgresql user.

Zdenek

Zdenek Kotala wrote:

The problem what Dhanaraj tries to address is how to secure solve
problem with PAM and local user. Other servers (e.g. sshd) allow to
run master under root (with limited privileges) and forked process
under normal user. But postgresql
requires start as non-root user. It limits to used common pattern.

There is important question:

Is current requirement to run postgresql under non-root OK? If yes,
than we must update PAM documentation to explain this situation which
will never works secure. Or if we say No, it is stupid limitation (in
case when UID 0 says nothing about user's privileges) then we must
start discussion about solution.

For now I think we should update the docs. You really can't compare
postgres with sshd - ssh connections are in effect autonomous. I suspect
the changes involved in allowing us to run as root and then give up
privileges safely would be huge, and the gain quite small.

I'd rather see an HBA fallback mechanism, which I suspect might overcome
most of the problems being encountered here.

cheers

andrew

On Mon, August 20, 2007 19:52, Andrew Dunstan wrote:

I'd rather see an HBA fallback mechanism, which I suspect might overcome
most of the problems being encountered here.

I implemented a form of that once, so on local connections you could do
ident mapping with fallback to PAM or some other password authentication.
That seemed useful, e.g. for granting non-interactive access to a program
running under a dedicated user and requiring a password from everyone
else. The implementation also allowed for a bit more flexibility in the
auth mechanism.

The main objections I recall were:

1. The protocol doesn't allow for multiple authentication prompts. My own
proposal didn't have that problem since it only introduced an "optional
ident" authentication that continued looking for a matching rule if the
current user name was not in the given map, but it's a problem for more
general approaches.

2. For real, fully generalized fallback, you'd also need to overhaul the
HBA config file format completely.

3. It was considered unsafe to add even the most limited of fallback
options, because the HBA config is designed to pick just one auth
mechanism for any connection attempt, based on only the first three
columns of the config file. An admin who didn't understand the new auth
mechanism could use it to write an unsafe HBA configuration, provided it
also broke the existing "go from specific-permissive to
general-restrictive" design guideline.

Personally I think it'd take some careful aim to shoot yourself in the
foot like that, but IIRC it was enough for an "I don't like it" vote.

Jeroen

Andrew Dunstan wrote:

Zdenek Kotala wrote:

The problem what Dhanaraj tries to address is how to secure solve
problem with PAM and local user. Other servers (e.g. sshd) allow to
run master under root (with limited privileges) and forked process
under normal user. But postgresql
requires start as non-root user. It limits to used common pattern.

There is important question:

Is current requirement to run postgresql under non-root OK? If yes,
than we must update PAM documentation to explain this situation which
will never works secure. Or if we say No, it is stupid limitation (in
case when UID 0 says nothing about user's privileges) then we must
start discussion about solution.

For now I think we should update the docs.

I agree.

I suspect
the changes involved in allowing us to run as root and then give up
privileges safely would be huge, and the gain quite small.

The main problem there is that there are a lot of different ways how to
do it and there is not standard. For example on Solaris applications use
RBAC functionality to handle privileges and this is not available on
other platforms and so on...

I'd rather see an HBA fallback mechanism, which I suspect might overcome
most of the problems being encountered here.

The question is why don't use fallback functionality guaranteed by PAM
and naming services. It seems that only fallback to or from password
auth makes sense. Other could be handled by PAM/naming.

Zdenek

Hi all,

This is the continuation to the discussion that we had in the hacker's list.

http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-PAM
Here, I like to add some details in 20.2.6. PAM authentication section.

Can someone review and make changes, if required? Thanks.

*** client-auth.sgml.orig       Tue Aug 21 16:52:45 2007
--- client-auth.sgml    Tue Aug 21 17:02:52 2007
***************
*** 987,992 ****
--- 987,1001 ----
      and the <ulink url="http://www.sun.com/software/solaris/pam/">
      <systemitem class="osname">Solaris</> PAM Page</ulink>.
     </para>
+
+    <note>
+     <para>
+      The local UNIX user authentication is not permitted,
+      because the postgres server is started by a non-root user.
+      In order to enable this functionality, the root user must provide
+      additional permissions to the postgres user (for reading 
/etc/shadow file).
+     </para>
+    </note>
    </sect2>
   </sect1>

Zdenek Kotala wrote:

The problem what Dhanaraj tries to address is how to secure solve
problem with PAM and local user. Other servers (e.g. sshd) allow to
run master under root (with limited privileges) and forked process
under normal user. But postgresql
requires start as non-root user. It limits to used common pattern.

There is important question:

Is current requirement to run postgresql under non-root OK? If yes,
than we must update PAM documentation to explain this situation which
will never works secure. Or if we say No, it is stupid limitation (in
case when UID 0 says nothing about user's privileges) then we must
start discussion about solution.

For now I think we should update the docs. You really can't compare
postgres with sshd - ssh connections are in effect autonomous. I
suspect the changes involved in allowing us to run as root and then
give up privileges safely would be huge, and the gain quite small.

I'd rather see an HBA fallback mechanism, which I suspect might
overcome most of the problems being encountered here.

cheers

andrew

--
================================
Dhanaraj M
x40049/+91-9880244950
Solaris RPE, Bangalore, India
http://blogs.sun.com/dhanarajm/
================================

Applied:

PAM does work authenticating against Unix system authentication
because the postgres server is started by a non-root user. In order
to enable this functionality, the root user must provide additional
permissions to the postgres user (for reading
<filename>/etc/shadow</>).

---------------------------------------------------------------------------

Dhanaraj M wrote:

Hi all,

This is the continuation to the discussion that we had in the hacker's list.

http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-PAM
Here, I like to add some details in 20.2.6. PAM authentication section.

Can someone review and make changes, if required? Thanks.

*** client-auth.sgml.orig       Tue Aug 21 16:52:45 2007
--- client-auth.sgml    Tue Aug 21 17:02:52 2007
***************
*** 987,992 ****
--- 987,1001 ----
and the <ulink url="http://www.sun.com/software/solaris/pam/">
<systemitem class="osname">Solaris</> PAM Page</ulink>.
</para>
+
+    <note>
+     <para>
+      The local UNIX user authentication is not permitted,
+      because the postgres server is started by a non-root user.
+      In order to enable this functionality, the root user must provide
+      additional permissions to the postgres user (for reading 
/etc/shadow file).
+     </para>
+    </note>
</sect2>
</sect1>

Zdenek Kotala wrote:

The problem what Dhanaraj tries to address is how to secure solve
problem with PAM and local user. Other servers (e.g. sshd) allow to
run master under root (with limited privileges) and forked process
under normal user. But postgresql
requires start as non-root user. It limits to used common pattern.

There is important question:

Is current requirement to run postgresql under non-root OK? If yes,
than we must update PAM documentation to explain this situation which
will never works secure. Or if we say No, it is stupid limitation (in
case when UID 0 says nothing about user's privileges) then we must
start discussion about solution.

For now I think we should update the docs. You really can't compare
postgres with sshd - ssh connections are in effect autonomous. I
suspect the changes involved in allowing us to run as root and then
give up privileges safely would be huge, and the gain quite small.

I'd rather see an HBA fallback mechanism, which I suspect might
overcome most of the problems being encountered here.

cheers

andrew

--
================================
Dhanaraj M
x40049/+91-9880244950
Solaris RPE, Bangalore, India
http://blogs.sun.com/dhanarajm/
================================

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +