>
> Well sure, but best effort is better than no effort at all. Preventing
> CREATE/ALTER will catch 99% of items, and as I advocated, there really is no
> reason for them to be in pg_stat_statements in the first place.
>
>>
>> The clients that set passwords could simply turn off track_utility on
On Tue, Feb 25, 2025 at 10:12 AM Sami Imseih wrote:
> > What about a more general solution, such as a flag to turn off logging
> of ALTER ROLE statements completely?
>
> IMO, flags for a specific type of utility statement seems way too much for
> pg_stat_statements, and this will also not complet
Sami Imseih writes:
>> What about a more general solution, such as a flag to turn off logging of
>> ALTER ROLE statements completely?
> IMO, flags for a specific type of utility statement seems way too much
> for pg_stat_statements, and this will also not completely prevent leaking
> plain text
> What about a more general solution, such as a flag to turn off logging of
> ALTER ROLE statements completely?
IMO, flags for a specific type of utility statement seems way too much
for pg_stat_statements, and this will also not completely prevent leaking
plain text passwords from all ways that
What about a more general solution, such as a flag to turn off logging of
ALTER ROLE statements completely? Does anyone really need to know the
standard deviation of the timings for "ALTER ROLE alice SET
work_mem='50MB'"? Let's be honest, there are a lot of things that go into
pg_stat_statements th
On 2025-02-24 Mo 11:04 AM, Peter Eisentraut wrote:
On 21.02.25 17:38, Andrew Dunstan wrote:
I don't think this is such a terrible kluge. I think it's different
from the server log case, which after all requires access to the
server file system to exploit.
To me, the mechanism by which this
Thanks for all the comments on this folks! I probably underestimated
this change.
Thanks all.
--
Matheus Alcantara
On 21.02.25 17:38, Andrew Dunstan wrote:
I don't think this is such a terrible kluge. I think it's different from
the server log case, which after all requires access to the server file
system to exploit.
To me, the mechanism by which this patch works is completely nonobvious
and coincidental
Matheus Alcantara writes:
> Attached a patch to redact the password value from pg_stat_statements_view
> when
> executing:
> { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED]
> PASSWORD 'value' }
Please see previous threads about hiding this sort of information,
most recently [1
Andrew Dunstan writes:
> On 2025-02-21 Fr 11:08 AM, Tom Lane wrote:
>> Please see previous threads about hiding this sort of information,
>> most recently [1]. It's a slippery slope for which there are no
>> real fixes, and even partial fixes like this one are horrid kluges.
> I don't think this
Greg Sabino Mullane writes:
> I'm wondering what else we can do to discourage this pattern, however.
> There are more secure ways to set/change a password, but we keep seeing
> plain text pop up in various contexts. Maybe a strong warning+hint when
> someone uses these commands? A future GUC to di
On 2025-02-21 Fr 11:08 AM, Tom Lane wrote:
Matheus Alcantara writes:
Attached a patch to redact the password value from pg_stat_statements_view when
executing:
{ CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED]
PASSWORD 'value' }
Please see previous threads about hiding this
> It's a slippery slope for which there are no
> real fixes, and even partial fixes like this one are horrid kluges.
+1,
For example I don't think the current patch can deal with passwords
set in ALTER/CREATE inside DO blocks, and there is probably not
a sensible way to deal with that either.
Re
The idea and the patch looks good to me at first glance, +1.
I'm wondering what else we can do to discourage this pattern, however.
There are more secure ways to set/change a password, but we keep seeing
plain text pop up in various contexts. Maybe a strong warning+hint when
someone uses these com
14 matches
Mail list logo
