Patch to include PAM support...

Saved for 7.2 in the patches mailbox.

As mentioned on -hackers, I added the neccesary code to PostgreSQL to
allow for authentication through PAM... Attached is the patch.

-Dominic

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

Content-Description:

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Is there any interest in PAM support? If not, I will reject this patch.

As mentioned on -hackers, I added the neccesary code to PostgreSQL to
allow for authentication through PAM... Attached is the patch.

-Dominic

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

Content-Description:

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian writes:

Is there any interest in PAM support? If not, I will reject this patch.

Sure there is.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Bruce Momjian writes:

Is there any interest in PAM support? If not, I will reject this patch.

Sure there is.

OK, care to give a thumbs up on the patch?

http://candle.pha.pa.us/cgi-bin/pgpatches

It is enabled with a compile-time option.

Tom objected to it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there any interest in PAM support? If not, I will reject this patch.

We have seen multiple requests for PAM support, so there's interest out
there. But IIRC, I had some serious concerns about this proposed
implementation.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Is there any interest in PAM support? If not, I will reject this patch.

We have seen multiple requests for PAM support, so there's interest out
there. But IIRC, I had some serious concerns about this proposed
implementation.

I know there was concerns about blocking but is that problem any more so
than other interfaces we already support?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I know there was concerns about blocking but is that problem any more so
than other interfaces we already support?

We don't need to make it worse. We've already had trouble reports about
postmaster hangups with broken IDENT servers; PAM will hugely expand the
scope of potential troubles. Can you say "denial of service"?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I know there was concerns about blocking but is that problem any more so
than other interfaces we already support?

We don't need to make it worse. We've already had trouble reports about
postmaster hangups with broken IDENT servers; PAM will hugely expand the
scope of potential troubles. Can you say "denial of service"?

Does it really? You are saying PAM can make "denial of service" attacks
even easier than ident?

If it is the same risk, I think it is OK, but if it is worse, I see your
point. (I don't know much about PAM except it allows authentication.)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Tue, Jun 12, 2001 at 11:56:12AM -0400, Bruce Momjian allegedly wrote:

Is there any interest in PAM support? If not, I will reject this patch.

Yeah, I would be interested. It would enable me to pull passwords from
LDAP, which should enable our helpdesk to support PostgreSQL better
(change requests for passwords now go via sysadmin, while all other
passwords (ftp, staging, accounts) are stored in a central repository).

However, to me it's more of a handy featured than a critical one.

Regards,

Mathijs
--
"Books constitute capital."
Thomas Jefferson

Bruce Momjian writes:

OK, care to give a thumbs up on the patch?

http://candle.pha.pa.us/cgi-bin/pgpatches

From static inspection I have some doubts about whether this patch would
operate correctly. The way it is implemented is that if the backend is
instructed to use PAM authentication it pretends to the frontend that
password authentication is going on. This would probably work correctly
if your PAM setup is that you require exactly one password from the user.
But if the PAM setup does not require a password (Kerberos, rhosts
modules?) it would involve a useless exchange (and possibly prompt) for a
password. More importantly, though, if the PAM configuration requires
more than one password (perhaps the password is due to be changed), this
implementation will fail (to authenticate).

Dominic, any comments?

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

On Tue, 12 Jun 2001, Bruce Momjian wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I know there was concerns about blocking but is that problem any more so
than other interfaces we already support?

We don't need to make it worse. We've already had trouble reports about
postmaster hangups with broken IDENT servers; PAM will hugely expand the
scope of potential troubles. Can you say "denial of service"?

Does it really? You are saying PAM can make "denial of service" attacks
even easier than ident?

If anything, then "possibly as easy as ident" - but that's a worst case
scenario. And the reason for that is because they both potentially use
outside server/services. PAM doesn't _have_ to authenticate into external
devices, the LDAP example is just an example from my/our situation. You
could use PAM to authenticate into the local system password file, and/or
use it to create user limits (Only 3 connections per user, as example..)

If it is the same risk, I think it is OK, but if it is worse, I see your
point. (I don't know much about PAM except it allows authentication.)

My apologies if PAM has somehow been equated to "remote server
authentication piece" - there is a lot more to PAM than the abillity to
easily do remote authentication.

http://www.kernel.org/pub/linux/libs/pam/whatispam.html
http://www.kernel.org/pub/linux/libs/pam/FAQ

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

On Tue, 12 Jun 2001, Peter Eisentraut wrote:

Bruce Momjian writes:

OK, care to give a thumbs up on the patch?

http://candle.pha.pa.us/cgi-bin/pgpatches

From static inspection I have some doubts about whether this patch would

operate correctly. The way it is implemented is that if the backend is
instructed to use PAM authentication it pretends to the frontend that
password authentication is going on. This would probably work correctly

Correct - this was to save code duplication - since the frontend steps for
password authentication are the same, whether you're authenticating to
global/pg_pwd, or handing off the username/password processing to PAM.

if your PAM setup is that you require exactly one password from the user.
But if the PAM setup does not require a password (Kerberos, rhosts
modules?) it would involve a useless exchange (and possibly prompt) for a

This works fine - if it doesn't require a password, it won't get to the
"password prompt" step inside the conversation function, and ends up just
returning "success".

password. More importantly, though, if the PAM configuration requires
more than one password (perhaps the password is due to be changed), this
implementation will fail (to authenticate).

Typical use of a database, is from a non-interactive interface (script,
application, et al), where you aren't given the abillity to enter a second
password in the first place. Granted, this could be implemented - but my
goal was to emulate the existing libpq authentication process (which only
allows for the transmission of one password for all (the one?) of the
existing authentication methods that utilize passwords.

In all of the other remote authentication pieces that I have worked
with/used (radius, tacacs, etc) - if your password is in need to be
changed and/or expired - your authentication just fails.

Dominic, any comments?

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

"Dominic J. Eidson" <sauron@the-infinite.org> writes:

My apologies if PAM has somehow been equated to "remote server
authentication piece" - there is a lot more to PAM than the abillity to
easily do remote authentication.

Right. Part of the reason I'm concerned is that if we support PAM,
then we don't *know* exactly what it is we are buying into or which
authentication protocol will be used. This doesn't bother me as long
as any PAM-induced failure is confined to the connection trying to use
a particular PAM auth mechanism. But it does bother me if such a problem
can cause denial of service for all clients.

We have this problem already with IDENT, and we know we need to fix it.
I'm just saying that we'd better fix it before we add PAM support, not
after.

regards, tom lane

"Dominic J. Eidson" <sauron@the-infinite.org> writes:

My apologies if PAM has somehow been equated to "remote server
authentication piece" - there is a lot more to PAM than the abillity to
easily do remote authentication.

Right. Part of the reason I'm concerned is that if we support PAM,
then we don't *know* exactly what it is we are buying into or which
authentication protocol will be used. This doesn't bother me as long
as any PAM-induced failure is confined to the connection trying to use
a particular PAM auth mechanism. But it does bother me if such a problem
can cause denial of service for all clients.

We have this problem already with IDENT, and we know we need to fix it.
I'm just saying that we'd better fix it before we add PAM support, not
after.

It is has the same problems as IDENT, and it doesn't add any new
problems, and it meets people's needs, why not add it? When we get
IDENT fixed we can fix PAM at the same time.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Dominic J. Eidson writes:

if your PAM setup is that you require exactly one password from the user.
But if the PAM setup does not require a password (Kerberos, rhosts
modules?) it would involve a useless exchange (and possibly prompt) for a

This works fine - if it doesn't require a password, it won't get to the
"password prompt" step inside the conversation function, and ends up just
returning "success".

In the patch I'm looking at, the conversation function doesn't do any
actual "prompting", it looks at the password that has previously been
obtained by way of the password packet exchange. If no password is
required, the password is never looked at, but still obtained. That by
itself causes psql to print a password prompt.

Perhaps this could work: In the switch in be_recvauth(), you call the
pam_authenticate() and friends and if the sequence passes you report back
"OK". In the conversation function -- if it gets called -- send a
password packet and store the answer packet. You might have to play some
tricks here to obtain the answer packet, though.

In all of the other remote authentication pieces that I have worked
with/used (radius, tacacs, etc) - if your password is in need to be
changed and/or expired - your authentication just fails.

Alright.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Bruce Momjian <pgman@candle.pha.pa.us> writes:

It is has the same problems as IDENT, and it doesn't add any new
problems, and it meets people's needs, why not add it?

Because (a) it greatly increases the scope of the vulnerability,
and (b) it adds more code that will need to be rewritten to fix the
problem. I want to fix the blocking problem first, then solicit a
PAM patch that fits into the rewritten postmaster.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

It is has the same problems as IDENT, and it doesn't add any new
problems, and it meets people's needs, why not add it?

Because (a) it greatly increases the scope of the vulnerability,

How? It is just a new authentication method with the same problems as
our current ones.

and (b) it adds more code that will need to be rewritten to fix the
problem. I want to fix the blocking problem first, then solicit a
PAM patch that fits into the rewritten postmaster.

This seems to fit into the "wait for the perfect fix" solution which I
don't think applies here. There is no saying that a PAM patch will even
be around once we get the rest working.

Basically, we have some people who want it. Now we need to hear from
people who don't want it. I have a "no" from Tom and a "yes" from
"Peter E" (and the author).

We need more votes to decide.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Because (a) it greatly increases the scope of the vulnerability,

How? It is just a new authentication method with the same problems as
our current ones.

No, it is not *a* new authentication method, it is an open interface
that could be plugged into almost anything. We need the top-level
postmaster process to be absolutely reliable; plugging into "almost
anything" is not conducive to reliability.

Besides, an hour ago you were ready to reject this patch for lack of
interest. Why are you suddenly so eager to ignore the risks and apply
it anyway?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Because (a) it greatly increases the scope of the vulnerability,

How? It is just a new authentication method with the same problems as
our current ones.

No, it is not *a* new authentication method, it is an open interface
that could be plugged into almost anything. We need the top-level
postmaster process to be absolutely reliable; plugging into "almost
anything" is not conducive to reliability.

But isn't that the responsibility of the administrator? They are
already responsible for the IDENT servers they use. Isn't this the same
thing.

Besides, an hour ago you were ready to reject this patch for lack of
interest. Why are you suddenly so eager to ignore the risks and apply
it anyway?

Because some have now said they want it and I do not see the _new_ risks.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026