Thread: Patch to include PAM support...
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/
Attachment
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 <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
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/
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: > 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
> 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 <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 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: > > 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
"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
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
> "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
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
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/
> 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
> 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
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
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:
>> 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
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
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
> 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
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
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
> 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
> 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
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/
"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