public inbox for [email protected]
help / color / mirror / Atom feedCredcheck- credcheck.max_auth_failure
14+ messages / 5 participants
[nested] [flat]
* Credcheck- credcheck.max_auth_failure
@ 2024-12-11 10:46 張宸瑋 <[email protected]>
2024-12-11 16:41 ` Re: Credcheck- credcheck.max_auth_failure Adrian Klaver <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
0 siblings, 2 replies; 14+ messages in thread
From: 張宸瑋 @ 2024-12-11 10:46 UTC (permalink / raw)
To: [email protected]
In the use of the Credcheck suite, the parameter
"credcheck.max_auth_failure = '3'" is set in the postgresql.conf file to
limit users from entering incorrect passwords more than three times, after
which their account will be locked. Due to certain requirements, I would
like to ask if there is a way or feature to set this parameter differently
for a specific user or role, so that it does not apply to them. I
considered using "credcheck.whitelist" to exclude certain accounts, but
this would cause all other parameters to apply as well, and the account
would still require the other password complexity settings. I only wish to
exclude the "credcheck.max_auth_failure" parameter. Thank you in advance
for your response, and I would appreciate any assistance you can provide!
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
@ 2024-12-11 16:41 ` Adrian Klaver <[email protected]>
1 sibling, 0 replies; 14+ messages in thread
From: Adrian Klaver @ 2024-12-11 16:41 UTC (permalink / raw)
To: 張宸瑋 <[email protected]>; [email protected]
On 12/11/24 02:46, 張宸瑋 wrote:
> In the use of the Credcheck suite, the parameter
> "credcheck.max_auth_failure = '3'" is set in the postgresql.conf file to
> limit users from entering incorrect passwords more than three times,
> after which their account will be locked. Due to certain requirements, I
> would like to ask if there is a way or feature to set this parameter
> differently for a specific user or role, so that it does not apply to
> them. I considered using "credcheck.whitelist" to exclude certain
> accounts, but this would cause all other parameters to apply as well,
> and the account would still require the other password complexity
> settings. I only wish to exclude the "credcheck.max_auth_failure"
> parameter. Thank you in advance for your response, and I would
> appreciate any assistance you can provide!
The issue you filed here:
https://github.com/HexaCluster/credcheck/issues/43
is the way to go to get the necessary assistance.
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
@ 2024-12-11 17:57 ` Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
1 sibling, 1 reply; 14+ messages in thread
From: Greg Sabino Mullane @ 2024-12-11 17:57 UTC (permalink / raw)
To: 張宸瑋 <[email protected]>; +Cc: [email protected]
On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <[email protected]> wrote:
> In the use of the Credcheck suite, the parameter
> "credcheck.max_auth_failure = '3'" is set in the postgresql.conf file to
> limit users from entering incorrect passwords more than three times, after
> which their account will be locked.
>
Won't that allow absolutely anyone to lock out anyone else, including
admins/superusers? Sounds like a bad idea to me.
> Due to certain requirements, I would like to ask if there is a way or
> feature to set this parameter differently for a specific user or role, so
> that it does not apply to them.
>
There is not, but there is always the credcheck.reset_superuser setting as
an emergency measure. I'd keep the password complexity settings and not
enable max_auth_failure at all, myself. Three strikes and you're out feels
pretty draconian. Is there a particular threat model that is driving that?
Cheers,
Greg
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
@ 2024-12-11 18:43 ` Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Ron Johnson @ 2024-12-11 18:43 UTC (permalink / raw)
To: pgsql-generallists.postgresql.org <[email protected]>
On Wed, Dec 11, 2024 at 12:57 PM Greg Sabino Mullane <[email protected]>
wrote:
> On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <[email protected]> wrote:
>
>> In the use of the Credcheck suite, the parameter
>> "credcheck.max_auth_failure = '3'" is set in the postgresql.conf file to
>> limit users from entering incorrect passwords more than three times, after
>> which their account will be locked.
>>
>
> Won't that allow absolutely anyone to lock out anyone else, including
> admins/superusers? Sounds like a bad idea to me.
>
Isn't this a pretty common password setting? I know that for at least 35
years, and going back to the VAX/VMS days I've been locked out for X hours
if I typed an invalid password. Same on Windows and I think also Linux
(though ssh public keys and clients remembering passwords mean that rarely
happens to me).
>
>
>> Due to certain requirements, I would like to ask if there is a way or
>> feature to set this parameter differently for a specific user or role, so
>> that it does not apply to them.
>>
>
> There is not, but there is always the credcheck.reset_superuser setting as
> an emergency measure. I'd keep the password complexity settings and not
> enable max_auth_failure at all, myself. Three strikes and you're out feels
> pretty draconian. Is there a particular threat model that is driving that?
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
@ 2024-12-13 20:23 ` Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Peter J. Holzer @ 2024-12-13 20:23 UTC (permalink / raw)
To: [email protected]
On 2024-12-11 13:43:38 -0500, Ron Johnson wrote:
> On Wed, Dec 11, 2024 at 12:57 PM Greg Sabino Mullane <[email protected]>
> wrote:
>
> On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <[email protected]> wrote:
>
> In the use of the Credcheck suite, the parameter
> "credcheck.max_auth_failure = '3'" is set in the postgresql.conf file
> to limit users from entering incorrect passwords more than three times,
> after which their account will be locked.
>
>
> Won't that allow absolutely anyone to lock out anyone else, including
> admins/superusers? Sounds like a bad idea to me.
>
>
> Isn't this a pretty common password setting?
Yes, but that doesn't mean it's a good idea.
Actually, let me tease that apart a bit.
It is very common for the setting to exist (probably just about any OS
and many applications, too), but much less common for it to be turned on.
There are good reasons for that.
Limiting the number of failed attempts makes a lot of sense for debit
cards: The PINs are short enough that a person could bruteforce all
combinations and that typos are uncommon. So multiple failed attempts
probably mean that the card was stolen. There is also no way to DOS
somebody, since you need the card before you can enter the PIN.
It may have made a bit of sense in the 1980s, when most people had short
and easily guessable passwords and hosts were typically only accessible
from directly connected terminals and not from the internet.
But it really doesn't make much sense now: Passwords should be so long
that brute-forcing them via login attempts is completely futile. Either
the attacker knows the password (then the limit doesn't help), or they
won't guess it in a million attempts (so the limit doesn't help either).
OTOH, the limit gives an attacker a very simple way to deny the service to
the legitimate used: Just enter a bogus password three times and boom -
account locked. (That threat can be mitigated by applying the limit per
IP address - but the attacker may have a botnet with a million nodes,
making the limit ineffective.)
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
@ 2024-12-16 10:32 ` 張宸瑋 <[email protected]>
2024-12-16 11:34 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 13:09 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-16 14:17 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
0 siblings, 3 replies; 14+ messages in thread
From: 張宸瑋 @ 2024-12-16 10:32 UTC (permalink / raw)
To: [email protected]
We have both regular accounts and system accounts. For regular accounts, we
still require password complexity and the lockout functionality after
multiple failed login attempts. However, for system accounts, due to
information security regulations, password complexity is also required. The
issue is that system accounts are used for system integration, and if the
account gets locked, it may affect system services, which could lead to
problems. To prevent this, we would like to exclude system accounts from
being affected by the credcheck.max_auth_failure parameter.
Peter J. Holzer <[email protected]>於 2024年12月14日 週六，上午4:24寫道：
> On 2024-12-11 13:43:38 -0500, Ron Johnson wrote:
> > On Wed, Dec 11, 2024 at 12:57 PM Greg Sabino Mullane <[email protected]
> >
> > wrote:
> >
> > On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <[email protected]> wrote:
> >
> > In the use of the Credcheck suite, the parameter
> > "credcheck.max_auth_failure = '3'" is set in the postgresql.conf
> file
> > to limit users from entering incorrect passwords more than three
> times,
> > after which their account will be locked.
> >
> >
> > Won't that allow absolutely anyone to lock out anyone else, including
> > admins/superusers? Sounds like a bad idea to me.
> >
> >
> > Isn't this a pretty common password setting?
>
> Yes, but that doesn't mean it's a good idea.
>
> Actually, let me tease that apart a bit.
>
> It is very common for the setting to exist (probably just about any OS
> and many applications, too), but much less common for it to be turned on.
>
> There are good reasons for that.
>
> Limiting the number of failed attempts makes a lot of sense for debit
> cards: The PINs are short enough that a person could bruteforce all
> combinations and that typos are uncommon. So multiple failed attempts
> probably mean that the card was stolen. There is also no way to DOS
> somebody, since you need the card before you can enter the PIN.
>
> It may have made a bit of sense in the 1980s, when most people had short
> and easily guessable passwords and hosts were typically only accessible
> from directly connected terminals and not from the internet.
>
> But it really doesn't make much sense now: Passwords should be so long
> that brute-forcing them via login attempts is completely futile. Either
> the attacker knows the password (then the limit doesn't help), or they
> won't guess it in a million attempts (so the limit doesn't help either).
> OTOH, the limit gives an attacker a very simple way to deny the service to
> the legitimate used: Just enter a bogus password three times and boom -
> account locked. (That threat can be mitigated by applying the limit per
> IP address - but the attacker may have a botnet with a million nodes,
> making the limit ineffective.)
>
> hp
>
> --
> _ | Peter J. Holzer | Story must make more sense than reality.
> |_|_) | |
> | | | [email protected] | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
@ 2024-12-16 11:34 ` Peter J. Holzer <[email protected]>
2 siblings, 0 replies; 14+ messages in thread
From: Peter J. Holzer @ 2024-12-16 11:34 UTC (permalink / raw)
To: [email protected]
On 2024-12-16 18:32:34 +0800, 張宸瑋 wrote:
> We have both regular accounts and system accounts. For regular accounts, we
> still require password complexity and the lockout functionality after multiple
> failed login attempts. However, for system accounts, due to information
> security regulations, password complexity is also required. The issue is that
> system accounts are used for system integration, and if the account gets
> locked, it may affect system services, which could lead to problems. To prevent
> this, we would like to exclude system accounts from being affected by the
> credcheck.max_auth_failure parameter.
Just in case it wasn't clear: My recommendation is to NOT use the
credcheck.max_auth_failure parameter for ANY account. It just causes
problems and doesn't really help. If you can't trust your users to
chooses sufficiently strong passwords, use a second factor. Or maybe
replace passwords with some other method (public keys, FIDO, ...)
altogether (in fact, I'd do that for system accounts).
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
@ 2024-12-16 13:09 ` Greg Sabino Mullane <[email protected]>
2024-12-16 14:13 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2 siblings, 1 reply; 14+ messages in thread
From: Greg Sabino Mullane @ 2024-12-16 13:09 UTC (permalink / raw)
To: 張宸瑋 <[email protected]>; +Cc: [email protected]
On Mon, Dec 16, 2024 at 5:32 AM 張宸瑋 <[email protected]> wrote:
> We have both regular accounts and system accounts. For regular accounts,
> we still require password complexity and the lockout functionality after
> multiple failed login attempts.
>
Again, what is the threat model here? Most people have their password in a
.pgpass file or similar, so it seems this only adds complexity and
annoyance without any real benefit.
However, for system accounts, due to information security regulations,
> password complexity is also required.
>
Yes, this makes sense.
> The issue is that system accounts are used for system integration, and if
> the account gets locked, it may affect system services, which could lead to
> problems. To prevent this, we would like to exclude system accounts from
> being affected by the credcheck.max_auth_failure parameter.
>
I think we all understand that, but the extension as it exists now cannot
do that. And the obvious and easiest solution is to stop using the denial
of service feature, which I am hoping is NOT mandated by security
regulations.
Cheers,
Greg
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-16 13:09 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
@ 2024-12-16 14:13 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Ron Johnson @ 2024-12-16 14:13 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: 張宸瑋 <[email protected]>; [email protected]
On Mon, Dec 16, 2024 at 8:10 AM Greg Sabino Mullane <[email protected]>
wrote:
> On Mon, Dec 16, 2024 at 5:32 AM 張宸瑋 <[email protected]> wrote:
>
>> We have both regular accounts and system accounts. For regular accounts,
>> we still require password complexity and the lockout functionality after
>> multiple failed login attempts.
>>
>
> Again, what is the threat model here?
>
I would not be surprised if the "threat model" is security auditors.
> Most people have their password in a .pgpass file or similar, so it seems
> this only adds complexity and annoyance without any real benefit.
>
Mostly, people *do not* log into our PG instances. 99% of connections are
from application service accounts via JDBC.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
@ 2024-12-16 14:17 ` Ron Johnson <[email protected]>
2024-12-16 15:18 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2 siblings, 1 reply; 14+ messages in thread
From: Ron Johnson @ 2024-12-16 14:17 UTC (permalink / raw)
To: pgsql-general
Local (socket-based) connections are typically peer-authenticated (meaning
that authentication is handled by Linux pam).
Thus, if someone enters too many wrong passwords for a superuser account,
you *should* still be able to locally connect to PG.
Better test it, though.
On Mon, Dec 16, 2024 at 5:32 AM 張宸瑋 <[email protected]> wrote:
> We have both regular accounts and system accounts. For regular accounts,
> we still require password complexity and the lockout functionality after
> multiple failed login attempts. However, for system accounts, due to
> information security regulations, password complexity is also required. The
> issue is that system accounts are used for system integration, and if the
> account gets locked, it may affect system services, which could lead to
> problems. To prevent this, we would like to exclude system accounts from
> being affected by the credcheck.max_auth_failure parameter.
>
>
> Peter J. Holzer <[email protected]>於 2024年12月14日 週六，上午4:24寫道：
>
>> On 2024-12-11 13:43:38 -0500, Ron Johnson wrote:
>> > On Wed, Dec 11, 2024 at 12:57 PM Greg Sabino Mullane <
>> [email protected]>
>> > wrote:
>> >
>> > On Wed, Dec 11, 2024 at 5:46 AM 張宸瑋 <[email protected]> wrote:
>> >
>> > In the use of the Credcheck suite, the parameter
>> > "credcheck.max_auth_failure = '3'" is set in the
>> postgresql.conf file
>> > to limit users from entering incorrect passwords more than
>> three times,
>> > after which their account will be locked.
>> >
>> >
>> > Won't that allow absolutely anyone to lock out anyone else,
>> including
>> > admins/superusers? Sounds like a bad idea to me.
>> >
>> >
>> > Isn't this a pretty common password setting?
>>
>> Yes, but that doesn't mean it's a good idea.
>>
>> Actually, let me tease that apart a bit.
>>
>> It is very common for the setting to exist (probably just about any OS
>> and many applications, too), but much less common for it to be turned on.
>>
>> There are good reasons for that.
>>
>> Limiting the number of failed attempts makes a lot of sense for debit
>> cards: The PINs are short enough that a person could bruteforce all
>> combinations and that typos are uncommon. So multiple failed attempts
>> probably mean that the card was stolen. There is also no way to DOS
>> somebody, since you need the card before you can enter the PIN.
>>
>> It may have made a bit of sense in the 1980s, when most people had short
>> and easily guessable passwords and hosts were typically only accessible
>> from directly connected terminals and not from the internet.
>>
>> But it really doesn't make much sense now: Passwords should be so long
>> that brute-forcing them via login attempts is completely futile. Either
>> the attacker knows the password (then the limit doesn't help), or they
>> won't guess it in a million attempts (so the limit doesn't help either).
>> OTOH, the limit gives an attacker a very simple way to deny the service to
>> the legitimate used: Just enter a bogus password three times and boom -
>> account locked. (That threat can be mitigated by applying the limit per
>> IP address - but the attacker may have a botnet with a million nodes,
>> making the limit ineffective.)
>>
>> hp
>>
>> --
>> _ | Peter J. Holzer | Story must make more sense than reality.
>> |_|_) | |
>> | | | [email protected] | -- Charles Stross, "Creative writing
>> __/ | http://www.hjp.at/ | challenge!"
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-16 14:17 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
@ 2024-12-16 15:18 ` Peter J. Holzer <[email protected]>
2024-12-16 15:37 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Peter J. Holzer @ 2024-12-16 15:18 UTC (permalink / raw)
To: [email protected]
On 2024-12-16 09:17:25 -0500, Ron Johnson wrote:
> Local (socket-based) connections are typically peer-authenticated
> (meaning that authentication is handled by Linux pam).
^^^
Is it? I haven't checked the source code, but this doesn't seem
plausible. You can get the uid of a socket peer directly from the
kernel, which can be converted to a user name via getpwuid, and the
mapping to postgresql roles is done via pg_ident.conf. I see no role for
PAM in that path.
> Thus, if someone enters too many wrong passwords for a superuser
> account, you should still be able to locally connect to PG.
True. But the client may not be on the same machine.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-16 14:17 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-16 15:18 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
@ 2024-12-16 15:37 ` Ron Johnson <[email protected]>
2024-12-17 18:39 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Ron Johnson @ 2024-12-16 15:37 UTC (permalink / raw)
To: [email protected]
On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer <[email protected]> wrote:
> On 2024-12-16 09:17:25 -0500, Ron Johnson wrote:
> > Local (socket-based) connections are typically peer-authenticated
> > (meaning that authentication is handled by Linux pam).
> ^^^
> Is it? I haven't checked the source code, but this doesn't seem
> plausible. You can get the uid of a socket peer directly from the
> kernel, which can be converted to a user name via getpwuid, and the
> mapping to postgresql roles is done via pg_ident.conf. I see no role for
> PAM in that path.
>
https://www.postgresql.org/docs/16/auth-peer.html
"
The peer authentication method works by obtaining the client's operating
system user name from the kernel and using it as the allowed database user
name (with optional user name mapping). This method is only supported on
local connections.
[snip]
Peer authentication is only available on operating systems providing the
getpeereid() function, the SO_PEERCRED socket parameter, or similar
mechanisms. Currently that includes Linux, most flavors of BSD including
macOS, and Solaris.
"
That means pam (and presumably also ldap and sssd), since there must be an
OS user with the same name, and OS authentication is handled by pam, ldap
and sssd.
$ grep peer '$PGDATA'/pg_hba.conf
local all all peer
>
> > Thus, if someone enters too many wrong passwords for a superuser
> > account, you should still be able to locally connect to PG.
>
> True. But the client may not be on the same machine.
>
> hp
>
> --
> _ | Peter J. Holzer | Story must make more sense than reality.
> |_|_) | |
> | | | [email protected] | -- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-16 14:17 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-16 15:18 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 15:37 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
@ 2024-12-17 18:39 ` Peter J. Holzer <[email protected]>
2024-12-17 18:47 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Peter J. Holzer @ 2024-12-17 18:39 UTC (permalink / raw)
To: [email protected]
On 2024-12-16 10:37:59 -0500, Ron Johnson wrote:
> On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer <[email protected]> wrote:
>
> On 2024-12-16 09:17:25 -0500, Ron Johnson wrote:
> > Local (socket-based) connections are typically peer-authenticated
> > (meaning that authentication is handled by Linux pam).
> ^^^
> Is it? I haven't checked the source code, but this doesn't seem
> plausible. You can get the uid of a socket peer directly from the
> kernel, which can be converted to a user name via getpwuid, and the
> mapping to postgresql roles is done via pg_ident.conf. I see no role for
> PAM in that path.
>
>
> https://www.postgresql.org/docs/16/auth-peer.html
>
> "
> The peer authentication method works by obtaining the client's operating system
> user name from the kernel and using it as the allowed database user name (with
> optional user name mapping). This method is only supported on local
> connections.
> [snip]
> Peer authentication is only available on operating systems providing the
> getpeereid() function, the SO_PEERCRED socket parameter, or similar mechanisms.
> Currently that includes Linux, most flavors of BSD including macOS, and Solaris
> .
> "
>
> That means pam
No, it doesn't. PAM is used to authenticate a user to the OS (plus to do
a bit of setup and teardown at the beginning and end of each session).
But here the user is already authenticated to the OS and postgresql is
using that information to authenticate the user to itself. This will use
the nsswitch mechanism on Linux (and probably something similar on the
other OSs) to do the uid->username lookup, but it will not use PAM,
since that simply isn't what PAM is for (or capable of to my knowledge).
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | [email protected] | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Credcheck- credcheck.max_auth_failure
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 17:57 ` Re: Credcheck- credcheck.max_auth_failure Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-13 20:23 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` Re: Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-16 14:17 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-16 15:18 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
2024-12-16 15:37 ` Re: Credcheck- credcheck.max_auth_failure Ron Johnson <[email protected]>
2024-12-17 18:39 ` Re: Credcheck- credcheck.max_auth_failure Peter J. Holzer <[email protected]>
@ 2024-12-17 18:47 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Ron Johnson @ 2024-12-17 18:47 UTC (permalink / raw)
To: [email protected]
On Tue, Dec 17, 2024 at 1:39 PM Peter J. Holzer <[email protected]> wrote:
> On 2024-12-16 10:37:59 -0500, Ron Johnson wrote:
> > On Mon, Dec 16, 2024 at 10:19 AM Peter J. Holzer <[email protected]>
> wrote:
> >
> > On 2024-12-16 09:17:25 -0500, Ron Johnson wrote:
> > > Local (socket-based) connections are typically peer-authenticated
> > > (meaning that authentication is handled by Linux pam).
> > ^^^
> > Is it? I haven't checked the source code, but this doesn't seem
> > plausible. You can get the uid of a socket peer directly from the
> > kernel, which can be converted to a user name via getpwuid, and the
> > mapping to postgresql roles is done via pg_ident.conf. I see no role
> for
> > PAM in that path.
> >
> >
> > https://www.postgresql.org/docs/16/auth-peer.html
> >
> > "
> > The peer authentication method works by obtaining the client's operating
> system
> > user name from the kernel and using it as the allowed database user name
> (with
> > optional user name mapping). This method is only supported on local
> > connections.
> > [snip]
> > Peer authentication is only available on operating systems providing the
> > getpeereid() function, the SO_PEERCRED socket parameter, or similar
> mechanisms.
> > Currently that includes Linux, most flavors of BSD including macOS,
> and Solaris
> > .
> > "
> >
> > That means pam
>
> No, it doesn't. PAM is used to authenticate a user to the OS (plus to do
> a bit of setup and teardown at the beginning and end of each session).
> But here the user is already authenticated to the OS and postgresql is
> using that information to authenticate the user to itself. This will use
> the nsswitch mechanism on Linux (and probably something similar on the
> other OSs) to do the uid->username lookup, but it will not use PAM,
> since that simply isn't what PAM is for (or capable of to my knowledge).
>
pam is _indirectly_ used, since like you said, that's what authenticates
the OS user that "peer" authentication needs.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2024-12-17 18:47 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-12-11 10:46 Credcheck- credcheck.max_auth_failure 張宸瑋 <[email protected]>
2024-12-11 16:41 ` Adrian Klaver <[email protected]>
2024-12-11 17:57 ` Greg Sabino Mullane <[email protected]>
2024-12-11 18:43 ` Ron Johnson <[email protected]>
2024-12-13 20:23 ` Peter J. Holzer <[email protected]>
2024-12-16 10:32 ` 張宸瑋 <[email protected]>
2024-12-16 11:34 ` Peter J. Holzer <[email protected]>
2024-12-16 13:09 ` Greg Sabino Mullane <[email protected]>
2024-12-16 14:13 ` Ron Johnson <[email protected]>
2024-12-16 14:17 ` Ron Johnson <[email protected]>
2024-12-16 15:18 ` Peter J. Holzer <[email protected]>
2024-12-16 15:37 ` Ron Johnson <[email protected]>
2024-12-17 18:39 ` Peter J. Holzer <[email protected]>
2024-12-17 18:47 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox