pam auth - add rhost item
Wheter it would be a problem to set additional item (rhost) before
pam_authentication function in backend/libpq/auth.c?
It is very useful because you can restrict access to given ip address like
in mysql.
And this actually utilized in pam-pgsql, wich cannot be used because rhost
item is empty.
Thanks.
Grzegorz.
On Mon, Oct 12, 2015 at 12:01 PM, kolo hhmow <grzsmp@gmail.com> wrote:
Wheter it would be a problem to set additional item (rhost) before
pam_authentication function in backend/libpq/auth.c?
It is very useful because you can restrict access to given ip address like
in mysql.
And this actually utilized in pam-pgsql, wich cannot be used because rhost
item is empty.
I can't understand what you are suggesting here. Perhaps you could be
more specific, or propose a patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Yes, sorry. I was in hurry when I posted this message.
I dont understand whay in CheckPAMAuth function only PAM_USER item is
adding to pam information before authenticate?
Wheter it would be a problem to set additional pam information like
PAM_RHOST which is very useful because we can use this item to restrict
access to this ip address.
I hope I'm more specific now and you will understand me.
Sorry, but I'm not native english speaker.
Patch in attachment, and link below to web-view on github:
https://github.com/grzsmp/postgres/commit/5e2b102ec6de27e786d627623dcb187e997609e4
On Tue, Oct 13, 2015 at 7:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Show quoted text
On Mon, Oct 12, 2015 at 12:01 PM, kolo hhmow <grzsmp@gmail.com> wrote:
Wheter it would be a problem to set additional item (rhost) before
pam_authentication function in backend/libpq/auth.c?
It is very useful because you can restrict access to given ip addresslike
in mysql.
And this actually utilized in pam-pgsql, wich cannot be used becauserhost
item is empty.
I can't understand what you are suggesting here. Perhaps you could be
more specific, or propose a patch.--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
auth.c.patchtext/x-patch; charset=US-ASCII; name=auth.c.patchDownload
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index aca4ffe..1cff899 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1736,7 +1736,9 @@ CheckPAMAuth(Port *port, char *user, char *password)
{
int retval;
pam_handle_t *pamh = NULL;
-
+ char hostinfo[NI_MAXHOST];
+ pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, NI_NUMERICHOST);
/*
* We can't entirely rely on PAM to pass through appdata --- it appears
* not to work on at least Solaris 2.6. So use these ugly static
@@ -1780,6 +1782,16 @@ CheckPAMAuth(Port *port, char *user, char *password)
pam_passwd = NULL; /* Unset pam_passwd */
return STATUS_ERROR;
}
+
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL; /* Unset pam_passwd */
+ return STATUS_ERROR;
+ }
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
On Tue, Oct 13, 2015 at 4:12 PM, kolo hhmow <grzsmp@gmail.com> wrote:
Yes, sorry. I was in hurry when I posted this message.
I dont understand whay in CheckPAMAuth function only PAM_USER item is adding
to pam information before authenticate?
Wheter it would be a problem to set additional pam information like
PAM_RHOST which is very useful because we can use this item to restrict
access to this ip address.
I hope I'm more specific now and you will understand me.
Sorry, but I'm not native english speaker.
Patch in attachment, and link below to web-view on github:
https://github.com/grzsmp/postgres/commit/5e2b102ec6de27e786d627623dcb187e997609e4
I don't personally know much about PAM, but if you want to restrict
access by IP, you could do that in pg_hba.conf.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Yes, but this is very ugly solution, becasue you have to restart postgresql
daemon each time you have added a new user.
This solution which I propose is give an abbility to dinamicaly manage user
accounts without need to restart each time a user account entry has change.
When you have lot of actively users using postgresql service, you cannot
restart the server each time somebody add, or remove some user account
entry from the system.
This is whay we uses pam modules with pam-pgsql and with this patch.
On Wed, Oct 14, 2015 at 9:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Show quoted text
On Tue, Oct 13, 2015 at 4:12 PM, kolo hhmow <grzsmp@gmail.com> wrote:
Yes, sorry. I was in hurry when I posted this message.
I dont understand whay in CheckPAMAuth function only PAM_USER item isadding
to pam information before authenticate?
Wheter it would be a problem to set additional pam information like
PAM_RHOST which is very useful because we can use this item to restrict
access to this ip address.
I hope I'm more specific now and you will understand me.
Sorry, but I'm not native english speaker.
Patch in attachment, and link below to web-view on github:https://github.com/grzsmp/postgres/commit/5e2b102ec6de27e786d627623dcb187e997609e4
I don't personally know much about PAM, but if you want to restrict
access by IP, you could do that in pg_hba.conf.--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Yes, you right - my mistake.
But editing pg_hba.conf with lot of entries is little inconveniet. When
using pam modules with backend database like postgresql/or whatever
is more efficient and convenient - this is whay among others I need pass
client ip to pam modules, and then to backend database for example.
So I'm waiting for comments from others.
Thanks.
On Wed, Oct 14, 2015 at 9:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Show quoted text
On Tue, Oct 13, 2015 at 4:12 PM, kolo hhmow <grzsmp@gmail.com> wrote:
Yes, sorry. I was in hurry when I posted this message.
I dont understand whay in CheckPAMAuth function only PAM_USER item isadding
to pam information before authenticate?
Wheter it would be a problem to set additional pam information like
PAM_RHOST which is very useful because we can use this item to restrict
access to this ip address.
I hope I'm more specific now and you will understand me.
Sorry, but I'm not native english speaker.
Patch in attachment, and link below to web-view on github:https://github.com/grzsmp/postgres/commit/5e2b102ec6de27e786d627623dcb187e997609e4
I don't personally know much about PAM, but if you want to restrict
access by IP, you could do that in pg_hba.conf.--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 14-10-2015 17:35, kolo hhmow wrote:
Yes, but this is very ugly solution, becasue you have to restart
postgresql daemon each time you have added a new user.
Restart != Reload. You can even do it using SQL.
This solution which I propose is give an abbility to dinamicaly manage
user accounts without need to restart each time a user account entry has
change.
Why do you want to double restrict the access? We already have HBA.
Also, you could complicate the management because you need to check two
different service configurations to figure out why foo user can't log
in. I'm not a PAM expert but my impression is that rhost is an optional
item. Therefore, advise PAM users to use HBA is a way to not complicate
the actual feature.
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Oct 15, 2015 at 1:45 AM, Euler Taveira <euler@timbira.com.br> wrote:
On 14-10-2015 17:35, kolo hhmow wrote:
Yes, but this is very ugly solution, becasue you have to restart
postgresql daemon each time you have added a new user.Restart != Reload. You can even do it using SQL.
Yes, this is was my mistake.
This solution which I propose is give an abbility to dinamicaly manage
user accounts without need to restart each time a user account entry has
change.Why do you want to double restrict the access? We already have HBA. Also,
you could complicate the management because you need to check two different
service configurations to figure out why foo user can't log in. I'm not a
PAM expert but my impression is that rhost is an optional item. Therefore,
advise PAM users to use HBA is a way to not complicate the actual feature.I have already explained this in my previous post. Did you read this?
So why postgresql give users an abbility to use a pam modules, when in
other side there is advice to not use them?
Anyway.
I do not see any complication with this approach. Just use one
configuration entry in pg_hba.conf, and rest entries in some database
backend of pam module, which is most convenient with lot of entries than
editing pg_hba.conf.
Yes rhost is optional item, which is not actually set to pam information in
ofical source code and this is why I need add this patch.
Show quoted text
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On 15-10-2015 05:41, kolo hhmow wrote:
I have already explained this in my previous post. Did you read this?
Yes, I do.
So why postgresql give users an abbility to use a pam modules, when in
other side there is advice to not use them?
Anyway.
Where is such advise? I can't see it in docs [1]http://www.postgresql.org/docs/current/static/auth-methods.html#AUTH-PAM.
I do not see any complication with this approach. Just use one
configuration entry in pg_hba.conf, and rest entries in some database
backend of pam module, which is most convenient with lot of entries than
editing pg_hba.conf.
Why don't you use a group role? I need just one entry in pg_hba.conf.
[1]: http://www.postgresql.org/docs/current/static/auth-methods.html#AUTH-PAM
[2]: http://www.postgresql.org/docs/current/static/role-membership.html
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 16, 2015 at 2:47 PM, Euler Taveira <euler@timbira.com.br> wrote:
On 15-10-2015 05:41, kolo hhmow wrote:
I have already explained this in my previous post. Did you read this?
Yes, I do.
So why postgresql give users an abbility to use a pam modules, when in
other side there is advice to not use them?
Anyway.Where is such advise? I can't see it in docs [1].
Not in docs. You gave such advice:
"Therefore, advise PAM users to use HBA is a way to not complicate the
actual feature".
I do not see any complication with this approach. Just use one
configuration entry in pg_hba.conf, and rest entries in some database
backend of pam module, which is most convenient with lot of entries than
editing pg_hba.conf.Why don't you use a group role? I need just one entry in pg_hba.conf.
[1]
http://www.postgresql.org/docs/current/static/auth-methods.html#AUTH-PAM
[2] http://www.postgresql.org/docs/current/static/role-membership.htmlBecause cannot restrict from what ip address client can connet in such way.
You can restrict only whole group, not just individual member of such
group, or I misunderstand something.
Show quoted text
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On Fri, Oct 16, 2015 at 8:47 AM, Euler Taveira <euler@timbira.com.br> wrote:
On 15-10-2015 05:41, kolo hhmow wrote:
I have already explained this in my previous post. Did you read this?
Yes, I do.
So why postgresql give users an abbility to use a pam modules, when in
other side there is advice to not use them?
Anyway.Where is such advise? I can't see it in docs [1].
I do not see any complication with this approach. Just use one
configuration entry in pg_hba.conf, and rest entries in some database
backend of pam module, which is most convenient with lot of entries than
editing pg_hba.conf.Why don't you use a group role? I need just one entry in pg_hba.conf.
I feel like this discussion has taken an unhelpful turn. Surely you
can see that this is not necessarily an exact substitute for what kolo
hhmow wants to do. Yeah, he could decide to do something else
instead, but are you really confused about why he would want to do
this in PAM, or is this just a case of arguing that what we have is
good enough so let's not change anything or take suggestions? He's
not saying there's no workaround; he's just saying he'd like this
better.
I think some more interesting questions are:
- Did he implement this correctly?
- Would it break anything?
- Are there lots of other knobs we should expose too instead of just one?
- What would it take to turn this into a committable patch?
- Would the cost of exposing this and perhaps some other knobs cost
too much in performance for the number of people it would make happy?
- If so, should the behavior be GUC-controlled or is there
justification for arguing we should drop the whole patch?
I feel like we've got somebody new showing up to our community with an
idea that is not obviously stupid. If we want such people to stick
around, we should try to give their ideas a fair shake.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
I think some more interesting questions are:
- Did he implement this correctly?
- Would it break anything?
- Are there lots of other knobs we should expose too instead of just one?
- What would it take to turn this into a committable patch?
- Would the cost of exposing this and perhaps some other knobs cost
too much in performance for the number of people it would make happy?
- If so, should the behavior be GUC-controlled or is there
justification for arguing we should drop the whole patch?
I agree with this set of questions -- the idea behind the patch seemed
quite reasonable to me.
I feel like we've got somebody new showing up to our community with an
idea that is not obviously stupid. If we want such people to stick
around, we should try to give their ideas a fair shake.
+1 to this, too.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16-10-2015 10:37, Robert Haas wrote:
- Did he implement this correctly?
- Would it break anything?
I did not review the patch.
- Are there lots of other knobs we should expose too instead of just one?
We are providing PAM_USER and PAM_CONV. The complete list of options are
[1]: http://pubs.opengroup.org/onlinepubs/8329799/pam_set_item.htm
(app) to user bar (PAM).
- What would it take to turn this into a committable patch?
Review?
- Would the cost of exposing this and perhaps some other knobs cost
too much in performance for the number of people it would make happy?
No.
- If so, should the behavior be GUC-controlled or is there
justification for arguing we should drop the whole patch?
The patch always set PAM_RHOST, ie. it means I can't disable it (at the
postgres side). Is it a problem? Of course the PAM module can provide a
way to ignore it but it is not our business.
I feel like we've got somebody new showing up to our community with an
idea that is not obviously stupid. If we want such people to stick
around, we should try to give their ideas a fair shake.
I share the same feeling. I wasn't trying to throw a cold water on it.
[1]: http://pubs.opengroup.org/onlinepubs/8329799/pam_set_item.htm
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 16, 2015 at 10:50 AM, Euler Taveira <euler@timbira.com.br> wrote:
I feel like we've got somebody new showing up to our community with an
idea that is not obviously stupid. If we want such people to stick
around, we should try to give their ideas a fair shake.I share the same feeling. I wasn't trying to throw a cold water on it.
OK, I felt like that's what you were doing. Sorry if I
misinterpreted, and thanks for clarifying.
kolo hhmow: I suggest adding your patch to
https://commitfest.postgresql.org/action/commitfest_view/open so it
doesn't get forgotten about. Hopefully someone who knows more about
this area will volunteer to review.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Ok.
Thak you all!
:)
On Fri, Oct 16, 2015 at 5:20 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Show quoted text
On Fri, Oct 16, 2015 at 10:50 AM, Euler Taveira <euler@timbira.com.br>
wrote:I feel like we've got somebody new showing up to our community with an
idea that is not obviously stupid. If we want such people to stick
around, we should try to give their ideas a fair shake.I share the same feeling. I wasn't trying to throw a cold water on it.
OK, I felt like that's what you were doing. Sorry if I
misinterpreted, and thanks for clarifying.kolo hhmow: I suggest adding your patch to
https://commitfest.postgresql.org/action/commitfest_view/open so it
doesn't get forgotten about. Hopefully someone who knows more about
this area will volunteer to review.--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sat, Oct 17, 2015 at 1:00 AM, kolo hhmow <grzsmp@gmail.com> wrote:
Ok.
Thak you all!
This patch was listed twice in the CF app. I removed the duplicated
entry and let this one alive:
https://commitfest.postgresql.org/7/392/
Could you add your name as an author please?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/13/15 4:12 PM, kolo hhmow wrote:
Yes, sorry. I was in hurry when I posted this message.
I dont understand whay in CheckPAMAuth function only PAM_USER item is
adding to pam information before authenticate?
Wheter it would be a problem to set additional pam information like
PAM_RHOST which is very useful because we can use this item to restrict
access to this ip address.
Your implementation uses NI_NUMERICHOST, but the documentation of
pam_set_item speaks of a "hostname". Which is correct?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Well, this is not matter since pam_set_item expect this argument as a
string.
Besides there is not always possible to get map from ip address to hostname.
So hostname is just a synonim for whatever information you cat get about
remote machine.
ps. sorry for delay answer.
Show quoted text
On 11/16/2015 04:24 AM, Peter Eisentraut wrote:
On 10/13/15 4:12 PM, kolo hhmow wrote:
Yes, sorry. I was in hurry when I posted this message.
I dont understand whay in CheckPAMAuth function only PAM_USER item is
adding to pam information before authenticate?
Wheter it would be a problem to set additional pam information like
PAM_RHOST which is very useful because we can use this item to restrict
access to this ip address.Your implementation uses NI_NUMERICHOST, but the documentation of
pam_set_item speaks of a "hostname". Which is correct?
Hi,
On 11/25/2015 01:45 PM, Grzegorz Sampolski wrote:
Well, this is not matter since pam_set_item expect this argument as a
string.
Besides there is not always possible to get map from ip address to
hostname. So hostname is just a synonim for whatever information you
cat get about remote machine.
I'm no PAM guru, but I don't see how this implies that we should
entirely abandon FQDN if it's available. Other tools relying on PAM have
to face the same question, so how do they address it?
For example this [1]https://fedorahosted.org/sssd/ticket/908 sssd ticket suggests that for example OpenSSH makes
this configurable - when UseDNS=yes then it attempts to resolve the IP
address to a FQDN, with UseDNS=no it passes the IP address without
attempting to use DNS.
[1]: https://fedorahosted.org/sssd/ticket/908
So maybe we need a knob for this, similar to UseDNS in OpenSSH?
Otherwise, the patch seems fine to me, except for whitespace issues.
Please, make sure you use tabs for indentation (and not spaces).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Actually, one more thing - the patch should probably update the docs
too, because client-auth.sgml currently says this in the "auth-pam" section:
<para>
...
PAM is used only to validate user name/password pairs.
...
</para>
I believe that's no longer true, because the patch adds PAM_RHOST to the
user/password fields.
Regarding the other PAM_* fields, none of them strikes me as very useful
for our use case.
In a broader sense, I think this patch is quite desirable, despite being
rather simple (which is good). I certainly don't agree with suggestions
that we can already do things like this through pg_hba.conf. If we're
providing PAM authentication, let's make it as complete/useful as
possible. In some cases modifying PAM may not be feasible - e.g. some
management systems rely on PAM as much as possible, and doing changes in
other ways is a major hassle.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 16, 2015 at 2:53 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
Actually, one more thing - the patch should probably update the docs too,
because client-auth.sgml currently says this in the "auth-pam" section:<para>
...
PAM is used only to validate user name/password pairs.
...
</para>I believe that's no longer true, because the patch adds PAM_RHOST to the
user/password fields.Regarding the other PAM_* fields, none of them strikes me as very useful for
our use case.In a broader sense, I think this patch is quite desirable, despite being
rather simple (which is good). I certainly don't agree with suggestions that
we can already do things like this through pg_hba.conf. If we're providing
PAM authentication, let's make it as complete/useful as possible. In some
cases modifying PAM may not be feasible - e.g. some management systems rely
on PAM as much as possible, and doing changes in other ways is a major
hassle.
There is no input from the author for more than 1 month, I have marked
the patch as returned with feedback because of a lack of activity.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi there!
I'm alive and working on new patch.
So, I takes into account all suggestions from Tomas and I'll
add additional parameter `usedns' with `yes/no' values to pass
resolved hostname or ip address through rhost_item.
On 12/24/2015 03:35 AM, Michael Paquier wrote:
On Wed, Dec 16, 2015 at 2:53 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:Actually, one more thing - the patch should probably update the docs too,
because client-auth.sgml currently says this in the "auth-pam" section:<para>
...
PAM is used only to validate user name/password pairs.
...
</para>I believe that's no longer true, because the patch adds PAM_RHOST to the
user/password fields.Regarding the other PAM_* fields, none of them strikes me as very useful for
our use case.In a broader sense, I think this patch is quite desirable, despite being
rather simple (which is good). I certainly don't agree with suggestions that
we can already do things like this through pg_hba.conf. If we're providing
PAM authentication, let's make it as complete/useful as possible. In some
cases modifying PAM may not be feasible - e.g. some management systems rely
on PAM as much as possible, and doing changes in other ways is a major
hassle.There is no input from the author for more than 1 month, I have marked
the patch as returned with feedback because of a lack of activity.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi.
I send new patch:
https://github.com/grzsmp/postgres/commit/3e3a1f187b71acef3f8dc0745da753fb5be821fa
On 12/27/2015 05:31 PM, Grzegorz Sampolski wrote:
Hi there!
I'm alive and working on new patch.
So, I takes into account all suggestions from Tomas and I'll
add additional parameter `usedns' with `yes/no' values to pass
resolved hostname or ip address through rhost_item.On 12/24/2015 03:35 AM, Michael Paquier wrote:
On Wed, Dec 16, 2015 at 2:53 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:Actually, one more thing - the patch should probably update the docs too,
because client-auth.sgml currently says this in the "auth-pam" section:<para>
...
PAM is used only to validate user name/password pairs.
...
</para>I believe that's no longer true, because the patch adds PAM_RHOST to the
user/password fields.Regarding the other PAM_* fields, none of them strikes me as very useful for
our use case.In a broader sense, I think this patch is quite desirable, despite being
rather simple (which is good). I certainly don't agree with suggestions that
we can already do things like this through pg_hba.conf. If we're providing
PAM authentication, let's make it as complete/useful as possible. In some
cases modifying PAM may not be feasible - e.g. some management systems rely
on PAM as much as possible, and doing changes in other ways is a major
hassle.There is no input from the author for more than 1 month, I have marked
the patch as returned with feedback because of a lack of activity.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi.
New patch available.
The new status of this patch is: Needs review
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Dec 28, 2015 at 03:01:07PM +0000, Grzegorz Sampolski wrote:
Hi.
New patch available.
Please attach the patch or patch set to your email just like else
does. :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi.
I thought link on commitfest to github url was sufficient.
Sorry. Attached new patch.
Show quoted text
On 12/28/2015 09:07 PM, David Fetter wrote:
Please attach the patch or patch set to your email just like else
does
Attachments:
pam_rhost_item.patchtext/x-patch; name=pam_rhost_item.patchDownload
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index cdc5bf1..d42cc76 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1735,6 +1735,20 @@ CheckPAMAuth(Port *port, char *user, char *password)
{
int retval;
pam_handle_t *pamh = NULL;
+ char hostinfo[NI_MAXHOST];
+
+ if (port->hba->pamusedns == true)
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, 0);
+ else
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, NI_NUMERICHOST);
+ if (retval) {
+ ereport(LOG,
+ (errmsg("(pam) couldn not determine the remote host information (%s)",
+ gai_strerror(retval))));
+ return STATUS_ERROR;
+ }
/*
* We can't entirely rely on PAM to pass through appdata --- it appears
@@ -1780,6 +1794,17 @@ CheckPAMAuth(Port *port, char *user, char *password)
return STATUS_ERROR;
}
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL;
+ return STATUS_ERROR;
+ }
+
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
if (retval != PAM_SUCCESS)
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 94f7cfa..db3fe3c 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1447,6 +1447,15 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
REQUIRE_AUTH_OPTION(uaPAM, "pamservice", "pam");
hbaline->pamservice = pstrdup(val);
}
+ else if (strcmp(name, "pamusedns") == 0)
+ {
+ REQUIRE_AUTH_OPTION(uaPAM, "pamusedns", "pam");
+ if (strcmp(val, "1") == 0)
+ hbaline->pamusedns = true;
+ else
+ hbaline->pamusedns = false;
+
+ }
else if (strcmp(name, "ldapurl") == 0)
{
#ifdef LDAP_API_FEATURE_X_OPENLDAP
diff --git a/src/include/libpq/hba.h b/src/include/libpq/hba.h
index 68a953a..f39240d 100644
--- a/src/include/libpq/hba.h
+++ b/src/include/libpq/hba.h
@@ -64,6 +64,7 @@ typedef struct HbaLine
char *usermap;
char *pamservice;
+ bool pamusedns;
bool ldaptls;
char *ldapserver;
int ldapport;
On Tue, Dec 29, 2015 at 12:46:40AM +0100, Grzegorz Sampolski wrote:
Hi.
I thought link on commitfest to github url was sufficient.
Sorry. Attached new patch.
Thanks!
My understanding for the reason behind the policy is that it is to
ensure that patch submissions are all together in a widely distributed
archive.
While github may seem like it's gigantic and eternal today, it may not
seem so ten years hence.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 29, 2015 at 10:46 AM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
I thought link on commitfest to github url was sufficient.
Sorry. Attached new patch.
I reviewed and tested the patch. With the addition of
new RHOST member to the passed items in the PAM
authentication doesn't have any impact with existing
behavior.
As Tomas said in up thread that RHOST is the item
that I also that can be added to PAM authentication.
I am not able to test PAM authentication using the
RHOST, can you please let me know the way for
the same?
And also the patch lacks of documentation changes,
As it adds the new pamusedns option and also it
sends the RHOST, so the documentation needs to be
updated.
Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Hari.
To use pam modules you can use whatever backend authentication method
you want.
This is example configuration:
Install this library https://github.com/pam-pgsql/pam-pgsql
Create some example database <database>, schema access and two tables:
pam_auth and pam_account with example defintion:
pam_account:
db_user character varying(16) NOT NULL,
host character varying(255) NOT NULL
pam_auth:
db_user character varying(16) NOT NULL,
password character varying(512) NOT NULL
Sample /etc/pam_pgsql.conf:
connect = dbname=<database> user=<user> password=<password>
auth_query = SELECT password FROM access.pam_auth WHERE db_user = %u LIMIT 1
acct_query = SELECT '0','0','' FROM access.pam_account WHERE db_user =
%u AND (host = %h OR %h LIKE host) ORDER BY host DESC LIMIT 1;
pw_type = crypt
Sample pam config /etc/pam.d/postgres_auth:
auth required pam_pgsql.so
account required pam_pgsql.so
Sample pg_hba.conf:
host samerole all 0.0.0.0/0 pam pamservice=postgres_auth
This will give you define access restriction from one host, group of
hosts, etc.
I will try to update documentation in regard to this chagnes, but please
take into account that my english isn't fluent so much. So if I'll do
some mistakes please correct me.
Regards.
Grzegorz Sampolski.
On 03/08/2016 05:30 AM, Haribabu Kommi wrote:
On Tue, Dec 29, 2015 at 10:46 AM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
I thought link on commitfest to github url was sufficient.
Sorry. Attached new patch.I reviewed and tested the patch. With the addition of
new RHOST member to the passed items in the PAM
authentication doesn't have any impact with existing
behavior.As Tomas said in up thread that RHOST is the item
that I also that can be added to PAM authentication.I am not able to test PAM authentication using the
RHOST, can you please let me know the way for
the same?And also the patch lacks of documentation changes,
As it adds the new pamusedns option and also it
sends the RHOST, so the documentation needs to be
updated.Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 8, 2016 at 10:43 PM, Grzegorz Sampolski <grzsmp@gmail.com>
wrote:
Hi Hari.
To use pam modules you can use whatever backend authentication method
you want.This is example configuration:
Install this library https://github.com/pam-pgsql/pam-pgsql
Create some example database <database>, schema access and two tables:
pam_auth and pam_account with example defintion:pam_account:
db_user character varying(16) NOT NULL,
host character varying(255) NOT NULLpam_auth:
db_user character varying(16) NOT NULL,
password character varying(512) NOT NULLSample /etc/pam_pgsql.conf:
connect = dbname=<database> user=<user> password=<password>
auth_query = SELECT password FROM access.pam_auth WHERE db_user = %u
LIMIT 1
acct_query = SELECT '0','0','' FROM access.pam_account WHERE db_user =
%u AND (host = %h OR %h LIKE host) ORDER BY host DESC LIMIT 1;
pw_type = crypt
Thanks for the details. I am able to test the host limitation based on
the host from where the connection request is given.This patch
provides the advantage of getting the connected host address
details for the PAM modules to provide/restrict the authentication.
A small change in the code, correct the following code from
+ if (retval) {
to
if (retval)
{
as per the code everywhere.
I will try to update documentation in regard to this chagnes, but please
take into account that my english isn't fluent so much. So if I'll do
some mistakes please correct me.
I am also not a good English speaker :), but we can try to provide to
as good as possible, later community can help in correcting it if they find
any problem/improvement.
Regards,
Hari Babu
Fujitsu Australia
Hi.
In attchment new patch with updated documentation and with small change
to coding style as you suggested.
Regards.
Grzegorz.
Show quoted text
On 03/09/2016 08:30 AM, Haribabu Kommi wrote:
On Tue, Mar 8, 2016 at 10:43 PM, Grzegorz Sampolski <grzsmp@gmail.com
<mailto:grzsmp@gmail.com>> wrote:Hi Hari.
To use pam modules you can use whatever backend authentication method
you want.This is example configuration:
Install this library https://github.com/pam-pgsql/pam-pgsql
Create some example database <database>, schema access and two tables:
pam_auth and pam_account with example defintion:pam_account:
db_user character varying(16) NOT NULL,
host character varying(255) NOT NULLpam_auth:
db_user character varying(16) NOT NULL,
password character varying(512) NOT NULLSample /etc/pam_pgsql.conf:
connect = dbname=<database> user=<user> password=<password>
auth_query = SELECT password FROM access.pam_auth WHERE db_user = %uLIMIT 1
acct_query = SELECT '0','0','' FROM access.pam_account WHERE db_user =
%u AND (host = %h OR %h LIKE host) ORDER BY host DESC LIMIT 1;
pw_type = cryptThanks for the details. I am able to test the host limitation based on
the host from where the connection request is given.This patch
provides the advantage of getting the connected host address
details for the PAM modules to provide/restrict the authentication.A small change in the code, correct the following code from
+if (retval) {
to
if (retval)
{as per the code everywhere.
I will try to update documentation in regard to this chagnes, but please
take into account that my english isn't fluent so much. So if I'll do
some mistakes please correct me.I am also not a good English speaker :), but we can try to provide to
as good as possible, later community can help in correcting it if they find
any problem/improvement.Regards,
Hari Babu
Fujitsu Australia
Attachments:
pam_auth.patchtext/x-patch; name=pam_auth.patchDownload
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 3b2935c..c43322d 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -1627,6 +1627,7 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
<para>
The following configuration options are supported for PAM:
<variablelist>
+
<varlistentry>
<term><literal>pamservice</literal></term>
<listitem>
@@ -1635,6 +1636,19 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><literal>pamusedns</literal></term>
+ <listitem>
+ <para>
+ When not set (which is default), then ip address of connected host
+ will be passed to pam modules through PAM_RHOST item.
+ Otherwise it will be an attempt to determine host's name which can lead
+ to login delays.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</para>
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index cdc5bf1..af0d641 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1735,6 +1735,21 @@ CheckPAMAuth(Port *port, char *user, char *password)
{
int retval;
pam_handle_t *pamh = NULL;
+ char hostinfo[NI_MAXHOST];
+
+ if (port->hba->pamusedns == true)
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, 0);
+ else
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, NI_NUMERICHOST);
+ if (retval)
+ {
+ ereport(LOG,
+ (errmsg("(pam) couldn not determine the remote host information (%s)",
+ gai_strerror(retval))));
+ return STATUS_ERROR;
+ }
/*
* We can't entirely rely on PAM to pass through appdata --- it appears
@@ -1780,6 +1795,17 @@ CheckPAMAuth(Port *port, char *user, char *password)
return STATUS_ERROR;
}
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL;
+ return STATUS_ERROR;
+ }
+
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
if (retval != PAM_SUCCESS)
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 94f7cfa..db3fe3c 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1447,6 +1447,15 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
REQUIRE_AUTH_OPTION(uaPAM, "pamservice", "pam");
hbaline->pamservice = pstrdup(val);
}
+ else if (strcmp(name, "pamusedns") == 0)
+ {
+ REQUIRE_AUTH_OPTION(uaPAM, "pamusedns", "pam");
+ if (strcmp(val, "1") == 0)
+ hbaline->pamusedns = true;
+ else
+ hbaline->pamusedns = false;
+
+ }
else if (strcmp(name, "ldapurl") == 0)
{
#ifdef LDAP_API_FEATURE_X_OPENLDAP
diff --git a/src/include/libpq/hba.h b/src/include/libpq/hba.h
index 68a953a..f39240d 100644
--- a/src/include/libpq/hba.h
+++ b/src/include/libpq/hba.h
@@ -64,6 +64,7 @@ typedef struct HbaLine
char *usermap;
char *pamservice;
+ bool pamusedns;
bool ldaptls;
char *ldapserver;
int ldapport;
On Fri, Mar 11, 2016 at 12:11 AM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
In attchment new patch with updated documentation and with small change
to coding style as you suggested.
Thanks for the update. Here I attached updated patch with additional
documentation
changes, If you are fine with the changes, I will mark the patch as
ready for committer.
Regards,
Hari Babu
Fujitsu Australia
Attachments:
pam_auth_updated.patchapplication/octet-stream; name=pam_auth_updated.patchDownload
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 3b2935c..51ab62d 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -1617,16 +1617,18 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
<literal>password</literal> except that it uses PAM (Pluggable
Authentication Modules) as the authentication mechanism. The
default PAM service name is <literal>postgresql</literal>.
- PAM is used only to validate user name/password pairs.
- Therefore the user must already exist in the database before PAM
- can be used for authentication. For more information about
- PAM, please read the <ulink url="http://www.kernel.org/pub/linux/libs/pam/">
+ PAM is used only to validate user name/password and connected
+ remote hostname/IP address. Therefore the user must already
+ exist in the database before PAM can be used for authentication.
+ For more information about PAM, please read the
+ <ulink url="http://www.kernel.org/pub/linux/libs/pam/">
<productname>Linux-PAM</> Page</ulink>.
</para>
<para>
The following configuration options are supported for PAM:
<variablelist>
+
<varlistentry>
<term><literal>pamservice</literal></term>
<listitem>
@@ -1635,6 +1637,20 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><literal>pamusedns</literal></term>
+ <listitem>
+ <para>
+ Parmater used to control the remote hostname/IP address that needs
+ to be sent to PAM authentication module. When not set (which is default),
+ then ip address of connected host will be passed to pam modules through
+ PAM_RHOST item. Otherwise the connected hostname is identified and passed.
+ An attempt to determine hostname may lead to login delays.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</para>
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 57c2f48..8445595 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1737,6 +1737,21 @@ CheckPAMAuth(Port *port, char *user, char *password)
{
int retval;
pam_handle_t *pamh = NULL;
+ char hostinfo[NI_MAXHOST];
+
+ if (port->hba->pamusedns == true)
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, 0);
+ else
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, NI_NUMERICHOST);
+ if (retval)
+ {
+ ereport(LOG,
+ (errmsg("(pam) couldn not determine the remote host information (%s)",
+ gai_strerror(retval))));
+ return STATUS_ERROR;
+ }
/*
* We can't entirely rely on PAM to pass through appdata --- it appears
@@ -1782,6 +1797,17 @@ CheckPAMAuth(Port *port, char *user, char *password)
return STATUS_ERROR;
}
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL;
+ return STATUS_ERROR;
+ }
+
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
if (retval != PAM_SUCCESS)
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 28f9fb5..089e575 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1447,6 +1447,15 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
REQUIRE_AUTH_OPTION(uaPAM, "pamservice", "pam");
hbaline->pamservice = pstrdup(val);
}
+ else if (strcmp(name, "pamusedns") == 0)
+ {
+ REQUIRE_AUTH_OPTION(uaPAM, "pamusedns", "pam");
+ if (strcmp(val, "1") == 0)
+ hbaline->pamusedns = true;
+ else
+ hbaline->pamusedns = false;
+
+ }
else if (strcmp(name, "ldapurl") == 0)
{
#ifdef LDAP_API_FEATURE_X_OPENLDAP
diff --git a/src/include/libpq/hba.h b/src/include/libpq/hba.h
index 68a953a..f39240d 100644
--- a/src/include/libpq/hba.h
+++ b/src/include/libpq/hba.h
@@ -64,6 +64,7 @@ typedef struct HbaLine
char *usermap;
char *pamservice;
+ bool pamusedns;
bool ldaptls;
char *ldapserver;
int ldapport;
Hi.
Thank you for improve documentation and yes I'm fine with this chages.
Regards.
Grzegorz.
On 03/12/2016 01:17 PM, Haribabu Kommi wrote:
On Fri, Mar 11, 2016 at 12:11 AM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
In attchment new patch with updated documentation and with small change
to coding style as you suggested.Thanks for the update. Here I attached updated patch with additional
documentation
changes, If you are fine with the changes, I will mark the patch as
ready for committer.Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Mar 13, 2016 at 8:07 AM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
Thank you for improve documentation and yes I'm fine with this chages.
Thanks. changed the patch status as ready for committer.
Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3/10/16 8:11 AM, Grzegorz Sampolski wrote:
In attchment new patch with updated documentation and with small change
to coding style as you suggested.
This patch seems fine. I'm not sure about the name "pamusedns" for the
option, since we use the OS resolver, which might not actually use DNS.
Maybe something like "pam_use_hostname"?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi.
Can be, but as you mentioned OS resolver can be configured to not use
dns at all. So much more appropriate will be pam_try_hostname if we want
to be more accurately.
But for me pamusedns, pam_use_hostname or pam_try_hostname all are
correct as either need to use some try to resolve ip address
irrespectively OS resolver use dns or not - I mean getnameinfo() not
give you such information if OS resolver use dns or not.
No to drug the discussion I can change pamusedns to pam_use_hostname if
you prefer.
On 03/16/2016 03:00 AM, Peter Eisentraut wrote:
On 3/10/16 8:11 AM, Grzegorz Sampolski wrote:
In attchment new patch with updated documentation and with small change
to coding style as you suggested.This patch seems fine. I'm not sure about the name "pamusedns" for the
option, since we use the OS resolver, which might not actually use DNS.
Maybe something like "pam_use_hostname"?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 16, 2016 at 10:46 PM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
Can be, but as you mentioned OS resolver can be configured to not use
dns at all. So much more appropriate will be pam_try_hostname if we want
to be more accurately.
But for me pamusedns, pam_use_hostname or pam_try_hostname all are
correct as either need to use some try to resolve ip address
irrespectively OS resolver use dns or not - I mean getnameinfo() not
give you such information if OS resolver use dns or not.
No to drug the discussion I can change pamusedns to pam_use_hostname if
you prefer.
+1 for pam_use_hostname.
Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Ok. So if no one objected to the evening - in my time zone ofcourse :)
I will change pamusedns to pam_use_hostname.
On 03/21/2016 08:43 AM, Haribabu Kommi wrote:
On Wed, Mar 16, 2016 at 10:46 PM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
Can be, but as you mentioned OS resolver can be configured to not use
dns at all. So much more appropriate will be pam_try_hostname if we want
to be more accurately.
But for me pamusedns, pam_use_hostname or pam_try_hostname all are
correct as either need to use some try to resolve ip address
irrespectively OS resolver use dns or not - I mean getnameinfo() not
give you such information if OS resolver use dns or not.
No to drug the discussion I can change pamusedns to pam_use_hostname if
you prefer.+1 for pam_use_hostname.
Regards,
Hari Babu
Fujitsu Australia
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
New patch, which change pamservice parameter from pamusedns to
pam_use_hostname.
Show quoted text
On 03/21/2016 10:59 AM, Grzegorz Sampolski wrote:
Ok. So if no one objected to the evening - in my time zone ofcourse :)
I will change pamusedns to pam_use_hostname.On 03/21/2016 08:43 AM, Haribabu Kommi wrote:
On Wed, Mar 16, 2016 at 10:46 PM, Grzegorz Sampolski <grzsmp@gmail.com> wrote:
Hi.
Can be, but as you mentioned OS resolver can be configured to not use
dns at all. So much more appropriate will be pam_try_hostname if we want
to be more accurately.
But for me pamusedns, pam_use_hostname or pam_try_hostname all are
correct as either need to use some try to resolve ip address
irrespectively OS resolver use dns or not - I mean getnameinfo() not
give you such information if OS resolver use dns or not.
No to drug the discussion I can change pamusedns to pam_use_hostname if
you prefer.+1 for pam_use_hostname.
Regards,
Hari Babu
Fujitsu Australia
Attachments:
pam_auth.patchtext/x-patch; name=pam_auth.patchDownload
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 3b2935c..a086b9a 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -1617,16 +1617,18 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
<literal>password</literal> except that it uses PAM (Pluggable
Authentication Modules) as the authentication mechanism. The
default PAM service name is <literal>postgresql</literal>.
- PAM is used only to validate user name/password pairs.
- Therefore the user must already exist in the database before PAM
- can be used for authentication. For more information about
- PAM, please read the <ulink url="http://www.kernel.org/pub/linux/libs/pam/">
+ PAM is used only to validate user name/password and connected
+ remote hostname/IP address. Therefore the user must already
+ exist in the database before PAM can be used for authentication.
+ For more information about PAM, please read the
+ <ulink url="http://www.kernel.org/pub/linux/libs/pam/">
<productname>Linux-PAM</> Page</ulink>.
</para>
<para>
The following configuration options are supported for PAM:
<variablelist>
+
<varlistentry>
<term><literal>pamservice</literal></term>
<listitem>
@@ -1635,6 +1637,20 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><literal>pam_use_hostname</literal></term>
+ <listitem>
+ <para>
+ Parmater used to control the remote hostname/IP address that needs
+ to be sent to PAM authentication module. When not set (which is default),
+ then ip address of connected host will be passed to pam modules through
+ PAM_RHOST item. Otherwise the connected hostname is identified and passed.
+ An attempt to determine hostname may lead to login delays.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</para>
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 7f1ae8c..3361daf 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1737,6 +1737,21 @@ CheckPAMAuth(Port *port, char *user, char *password)
{
int retval;
pam_handle_t *pamh = NULL;
+ char hostinfo[NI_MAXHOST];
+
+ if (port->hba->pam_use_hostname == true)
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, 0);
+ else
+ retval = pg_getnameinfo_all(&port->raddr.addr, port->raddr.salen,
+ hostinfo, sizeof(hostinfo), NULL, 0, NI_NUMERICHOST);
+ if (retval)
+ {
+ ereport(LOG,
+ (errmsg("(pam) couldn not determine the remote host information (%s)",
+ gai_strerror(retval))));
+ return STATUS_ERROR;
+ }
/*
* We can't entirely rely on PAM to pass through appdata --- it appears
@@ -1782,6 +1797,17 @@ CheckPAMAuth(Port *port, char *user, char *password)
return STATUS_ERROR;
}
+ retval = pam_set_item(pamh, PAM_RHOST, hostinfo);
+
+ if (retval != PAM_SUCCESS)
+ {
+ ereport(LOG,
+ (errmsg("pam_set_item(PAM_RHOST) failed: %s",
+ pam_strerror(pamh, retval))));
+ pam_passwd = NULL;
+ return STATUS_ERROR;
+ }
+
retval = pam_set_item(pamh, PAM_CONV, &pam_passw_conv);
if (retval != PAM_SUCCESS)
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 28f9fb5..5a39746 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1447,6 +1447,15 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline, int line_num)
REQUIRE_AUTH_OPTION(uaPAM, "pamservice", "pam");
hbaline->pamservice = pstrdup(val);
}
+ else if (strcmp(name, "pam_use_hostname") == 0)
+ {
+ REQUIRE_AUTH_OPTION(uaPAM, "pam_use_hostname", "pam");
+ if (strcmp(val, "1") == 0)
+ hbaline->pam_use_hostname = true;
+ else
+ hbaline->pam_use_hostname = false;
+
+ }
else if (strcmp(name, "ldapurl") == 0)
{
#ifdef LDAP_API_FEATURE_X_OPENLDAP
diff --git a/src/include/libpq/hba.h b/src/include/libpq/hba.h
index 68a953a..b306baf 100644
--- a/src/include/libpq/hba.h
+++ b/src/include/libpq/hba.h
@@ -64,6 +64,7 @@ typedef struct HbaLine
char *usermap;
char *pamservice;
+ bool pam_use_hostname;
bool ldaptls;
char *ldapserver;
int ldapport;
On 03/22/2016 04:29 PM, Grzegorz Sampolski wrote:
New patch, which change pamservice parameter from pamusedns to
pam_use_hostname.
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers