Re: Providing catalog view to pg_hba.conf file - Patch submission

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Date: 2015-02-28 02:06:41
Message-ID: 20150228020641.GX29780@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > I understand that there may be objections to that on the basis that it's
> > work that's (other than for this case) basically useless,
>
> Got it in one.

Meh. It's hardly all that difficult and it's not useless if the user
wants to look at it.

> I'm also not terribly happy about leaving security-relevant data sitting
> around in backend memory 100% of the time. We have had bugs that exposed
> backend memory contents for reading without also granting the ability to
> execute arbitrary code, so I think doing this does represent a
> quantifiable decrease in the security of pg_hba.conf.

How is that any different from today? The only time it's not *already*
in backend memory is when the user has happened to go through and make a
change and used reload (instead of restart) and then it's not so much
that the security sensetive information isn't there, it's just out of
date.

I'm not entirely against the idea of changing how things are today, but
this argument simply doesn't apply to the current state of things.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-02-28 02:12:36 Re: Providing catalog view to pg_hba.conf file - Patch submission
Previous Message Stephen Frost 2015-02-28 01:58:53 Re: deparsing utility commands