Thread: pam auth - add rhost item

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

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

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,
Suporte24x7 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].

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

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

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]. Maybe PAM_RUSER? BTW, we could use pg_ident.conf to map user foo 
(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,
Suporte24x7 e Treinamento
 

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

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?

Well, this is not matter since pam_set_item expect this argument as a string.<br /> Besides there is not always
possibleto get map from ip address to hostname.<br /> So hostname is just a synonim for whatever information you cat
getabout remote machine.<br /><br /> ps. sorry for delay answer.<br /><br /><div class="moz-cite-prefix">On 11/16/2015
04:24AM, Peter Eisentraut wrote:<br /></div><blockquote cite="mid:56494C6C.9010108@gmx.net" type="cite"><pre wrap="">On
10/13/154:12 PM, kolo hhmow wrote:
 
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
Your implementation uses NI_NUMERICHOST, but the documentation of
pam_set_item speaks of a "hostname".  Which is correct?

</pre></blockquote><br />

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

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

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

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.

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.

Hi.
New patch available.

The new status of this patch is: Needs review

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

Hi.
I thought link on commitfest to github url was sufficient.
Sorry. Attached new patch.

On 12/28/2015 09:07 PM, David Fetter wrote:
> Please attach the patch or patch set to your email just like else
> does

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

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

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
> 

Hi.
In attchment new patch with updated documentation and with small change
to coding style as you suggested.

Regards.
Grzegorz.

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

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

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
> 

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

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

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

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

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
> 

New patch, which change pamservice parameter from pamusedns to
pam_use_hostname.

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

On 03/22/2016 04:29 PM, Grzegorz Sampolski wrote:
> New patch, which change pamservice parameter from pamusedns to
> pam_use_hostname.

committed