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/
Fri, 27 Apr 2001 10:39:10 -0500 (CDT)
"Dominic J. Eidson" <sauron@the-infinite.org>
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

Fri, 27 Apr 2001 13:41:13 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...

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

Tue, 12 Jun 2001 11:56:12 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
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


Tue, 12 Jun 2001 18:24:57 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Patch to include PAM support...
> 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

Tue, 12 Jun 2001 12:27:44 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
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

Tue, 12 Jun 2001 12:32:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> 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

Tue, 12 Jun 2001 12:35:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
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

Tue, 12 Jun 2001 12:44:57 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> 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

Tue, 12 Jun 2001 12:55:04 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
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 

Tue, 12 Jun 2001 19:09:57 +0200
Mathijs Brands <mathijs@ilse.nl>
Re: Patch to include PAM support...
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


Tue, 12 Jun 2001 19:12:58 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Patch to include PAM support...
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/


Tue, 12 Jun 2001 12:19:59 -0500 (CDT)
"Dominic J. Eidson" <sauron@the-infinite.org>
Re: Patch to include PAM support...
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/


Tue, 12 Jun 2001 12:29:04 -0500 (CDT)
"Dominic J. Eidson" <sauron@the-infinite.org>
Re: Patch to include PAM support...
"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

Tue, 12 Jun 2001 13:40:49 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> "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

Tue, 12 Jun 2001 13:59:24 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
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


Tue, 12 Jun 2001 20:16:14 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Patch to include PAM support...
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

Tue, 12 Jun 2001 14:23:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> 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

Tue, 12 Jun 2001 14:31:58 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
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

Tue, 12 Jun 2001 14:44:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> 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

Tue, 12 Jun 2001 14:57:00 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> But isn't that the responsibility of the administrator?  They are
> already responsible for the IDENT servers they use.

Doesn't stop us from getting questions/complaints when it doesn't work.

			regards, tom lane

Tue, 12 Jun 2001 15:01:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > But isn't that the responsibility of the administrator?  They are
> > already responsible for the IDENT servers they use.
> 
> Doesn't stop us from getting questions/complaints when it doesn't work.

We are not getting flooded with IDENT problem reports, are we?

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

Tue, 12 Jun 2001 15:02:25 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
Peter Eisentraut <peter_e@gmx.net> writes:
> ... 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).

I *think* that the FE protocol will support more than one round of
password challenge, although given the lack of any way for the PAM
module to direct what prompt is given, that is unlikely to work
pleasantly.

The larger issue is how a PAM auth method of unknown characteristics
is going to fit into our existing FE/BE protocol.  It would seem to me
that a protocol extension will be required.  Lying to the frontend about
what is happening is very unlikely to prove workable in the long run.
What if the selected PAM auth method requires the client side to respond
in some special way?

			regards, tom lane

Tue, 12 Jun 2001 15:07:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
Tom Lane writes:

> The larger issue is how a PAM auth method of unknown characteristics
> is going to fit into our existing FE/BE protocol.  It would seem to me
> that a protocol extension will be required.  Lying to the frontend about
> what is happening is very unlikely to prove workable in the long run.
> What if the selected PAM auth method requires the client side to respond
> in some special way?

The interaction that a PAM stack can initiate is limited to prompting for
one or more values and getting strings as an answer.  The PAM-using
application registers a "conversation function" callback, which is
responsible for issuing the prompt and getting at the data in an
application-specific manner.  Ideally, the libpq protocol and API would be
extended to support this generality, but based on Dominic's comments the
password exchange would work to support the useful subset of this
functionality without any protocol or API changes.

Most of the time, PAM is used as a wrapper around some password database
like NIS or LDAP (or maybe even PostgreSQL).

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


Tue, 12 Jun 2001 22:02:52 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Patch to include PAM support... 
Peter Eisentraut <peter_e@gmx.net> writes:
> The interaction that a PAM stack can initiate is limited to prompting for
> one or more values and getting strings as an answer.

We could do that full-up, if only the FE/BE protocol included a prompt
string in the outgoing password request.  However, given the difficulty
of reprogramming clients to cope with multiple password challenges,
you're probably right that handling the single-password case without
any protocol or client API change is the wiser course.

However, I'm still quite concerned about letting the postmaster ignore
its other clients while it's executing a PAM auth cycle that will
invoke who-knows-what processing.  What's your take on that point?

			regards, tom lane

Tue, 12 Jun 2001 16:26:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> The interaction that a PAM stack can initiate is limited to prompting for
> one or more values and getting strings as an answer.  The PAM-using
> application registers a "conversation function" callback, which is
> responsible for issuing the prompt and getting at the data in an
> application-specific manner.  Ideally, the libpq protocol and API would be
> extended to support this generality, but based on Dominic's comments the
> password exchange would work to support the useful subset of this
> functionality without any protocol or API changes.
> 
> Most of the time, PAM is used as a wrapper around some password database
> like NIS or LDAP (or maybe even PostgreSQL).

We now have enough "yes" votes to apply this patch.  I will give another
day for comments on the patch's contents.

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

Wed, 13 Jun 2001 10:08:37 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
Bruce Momjian writes:

> 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).

Not in the current form.

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


Wed, 13 Jun 2001 17:18:30 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Patch to include PAM support...
Peter Eisentraut <peter_e@gmx.net> writes:
>> 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).

> Not in the current form.

I think Peter's main objection was that it'd always prompt for a
password whether needed or not.

Could we change the PAM code so that it tries to run the PAM auth cycle
immediately on receipt of a connection request?  If it gets a callback
for a password, it abandons the PAM conversation, sends off a password
request packet, and then tries again when the password comes back.

Of course, this would be hugely simpler if the work were being done in
a dedicated forked child of the postmaster ;-) ;-) ... just send the
request packet when PAM asks for a password, and sleep till it comes
back.

			regards, tom lane

Wed, 13 Jun 2001 11:31:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Patch to include PAM support... 
> Peter Eisentraut <peter_e@gmx.net> writes:
> >> 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).
> 
> > Not in the current form.
> 
> I think Peter's main objection was that it'd always prompt for a
> password whether needed or not.

OK, let's let Dominic work on that.  Now that there is a strong chance
that the patch will be applied, I am sure he can try 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

Wed, 13 Jun 2001 11:33:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
> Peter Eisentraut <peter_e@gmx.net> writes:
> >> 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).
> 
> > Not in the current form.
> 
> I think Peter's main objection was that it'd always prompt for a
> password whether needed or not.

I am on IRC with the author now and he is working on it.  It is actually
pretty nice to be on IRC while working on a patch because you can ask
questions and stuff.  Channel #postgresql on EfNet.

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

Wed, 13 Jun 2001 11:54:28 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Patch to include PAM support...
On Wed, 13 Jun 2001, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
> >> 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).
> 
> > Not in the current form.
> 
> I think Peter's main objection was that it'd always prompt for a
> password whether needed or not.

Okay, after many months of lurking, I've finally set aside some time this
last week to actually finish up the code. (It's been mostly-merged/working
since about a week after Tom sent the mail I'm replying to - but then my
employer decided it would be good for us (read: me) to finish working on a
project which has consumed 99% of any programming motivation I could
muster.

> Could we change the PAM code so that it tries to run the PAM auth cycle
> immediately on receipt of a connection request?  If it gets a callback
> for a password, it abandons the PAM conversation, sends off a password
> request packet, and then tries again when the password comes back.

I am attempting to do this in a way that's relatively elegant, and the
code should get sent to -patches tomorrow sometime , after I've had time
to do some testing.


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











Fri, 24 Aug 2001 20:46:07 -0500 (CDT)
"Dominic J. Eidson" <sauron@the-infinite.org>
Re: [PATCHES] Patch to include PAM support... 
"Dominic J. Eidson" <sauron@the-infinite.org> writes:
>> Could we change the PAM code so that it tries to run the PAM auth cycle
>> immediately on receipt of a connection request?  If it gets a callback
>> for a password, it abandons the PAM conversation, sends off a password
>> request packet, and then tries again when the password comes back.

> I am attempting to do this in a way that's relatively elegant, and the
> code should get sent to -patches tomorrow sometime , after I've had time
> to do some testing.

I think that the main objection to the original form of the PAM patch
was that it would lock up the postmaster until the client responded.
However, that is *not* a concern any longer, since the current code
forks first and authenticates after.  Accordingly, you shouldn't be
complexifying the PAM code to avoid waits.

			regards, tom lane

Sat, 25 Aug 2001 00:47:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: [PATCHES] Patch to include PAM support... 
On Sat, 25 Aug 2001, Tom Lane wrote:

> "Dominic J. Eidson" <sauron@the-infinite.org> writes:
> >> Could we change the PAM code so that it tries to run the PAM auth cycle
> >> immediately on receipt of a connection request?  If it gets a callback
> >> for a password, it abandons the PAM conversation, sends off a password
> >> request packet, and then tries again when the password comes back.
> 
> > I am attempting to do this in a way that's relatively elegant, and the
> > code should get sent to -patches tomorrow sometime , after I've had time
> > to do some testing.
> 
> I think that the main objection to the original form of the PAM patch
> was that it would lock up the postmaster until the client responded.
> However, that is *not* a concern any longer, since the current code
> forks first and authenticates after.  Accordingly, you shouldn't be
> complexifying the PAM code to avoid waits.

The complexity comes from getting PAM to only send a password request to
the frontend if the PAM authentication needs a password, and not
otherwise. As I'd mentioned to Bruce before, I think PAM authentication
should be treated like password authentication - if there's a potential
that a password might be required, request a password, whether it's needed
or not. But PeterE asked that it only request a password if a password is
needed, so I'm fighting to get it to do exactly that.

(I already knew auth is done in the backend, and therefor can be blocking :)


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


Sat, 25 Aug 2001 00:16:49 -0500 (CDT)
"Dominic J. Eidson" <sauron@the-infinite.org>
Re: Re: [PATCHES] Patch to include PAM support... 