exposing pg_controldata and pg_config as functions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/20/2015 06:59 AM, Andrew Dunstan wrote:

Is there any significant interest in either of these?

Josh Berkus tells me that he would like pg_controldata information,
and I was a bit interested in pg_config information, for this
reason: I had a report of someone who had configured using
--with-libxml but the xml tests actually returned the results that
are expected without xml being configured. The regression tests
thus passed, but should not have. It occurred to me that if we had
a test like

select pg_config('configure') ~ '--with-libxml' as has_xml;

in the xml tests then this failure mode would be detected.

I've found use for them both in the past. A fair amount of bit-rot has
set it no doubt, and these were quick and dirty to begin with, but I
have these hacks from a while back:

https://github.com/jconway/pg_config
https://github.com/jconway/pg_controldata

- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV1epAAAoJEDfy90M199hlDjkP/AjAMtF4Q4rwfy5CsqA1rCgX
E/hLoTxExwU11nS2Q6IxC1unsXCDQrr2lkutKsw5Ybo78O7pMvR39GqShQ6ItaOr
xLxkYmxU1pEC4MAzZ6TR7RCAiP5SOgDEC3X6ArBqc0zub6FrnuYI3zv8eIgcTWqT
cFan4vCHYZnWUp3KQ0sOpSl4I/5jeW3AwrfTlnwskC8NwpP0Oa0DiXXTtXoRUYZI
CaWUsV9FgfzGvhyQCJpwcldEU9TprU24U09CpIVzSmw6Q9eQBHO4k+nT/Xw3BRjH
LxPM7gH9LweQOJhzP3J8agrJqbnSntayPZKG9ZsqMvC/8Ly+mlIO/X4cuEYpKO94
De9jO+aly6NhUdCpOdM6cZdqsTggXExaafl61wazYBUcLWotBnL9I1E9n59fm+yu
wgec7vdWIzZn6FYr+Ox2sgOBbxXVs3l/FLTCkoUgsZWRvlEL/naePr5TxMJMyqpo
pt15r1WRd4KwDEN4qxYHrzOab/T7QG1RS9Qr2v0GMPvQp4lIXgCq2aJJXy+iCDPE
lifDpHipk39h0r0RN377UFmfW3Z8DNLj0UQpuw+bOXtFLZpcA4WQdg64qXBaUU26
7icScC7+PpEr+HialFyA8lbDb9EVRrUaJ6CJajrGy8iuH/vpME2+40sgFTvavZtk
a0mfnPIdWJjzkldZGZ23
=hbBg
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/20/2015 07:54 AM, Joe Conway wrote:

On 08/20/2015 06:59 AM, Andrew Dunstan wrote:

I was a bit interested in pg_config information, for this reason:
I had a report of someone who had configured using --with-libxml
but the xml tests actually returned the results that are expected
without xml being configured. The regression tests thus passed,
but should not have. It occurred to me that if we had a test
like

select pg_config('configure') ~ '--with-libxml' as has_xml;

in the xml tests then this failure mode would be detected.

I've found use for them both in the past. A fair amount of bit-rot
has set it no doubt, and these were quick and dirty to begin with,
but I have these hacks from a while back:

https://github.com/jconway/pg_config

The attached implements pg_config as a backend SRF and a matching
system view. A few notes:

1) The syntax is a bit different than what Andrew proposed:

8<----------------
select setting ~ '--with-libxml' as has_xml
from pg_config
where name = 'CONFIGURE';
has_xml
- ---------
t
(1 row)
8<----------------

In particular note that the name values are all upper case to be
consistent with pg_config, and at least currently there is no version
of the function which accepts a name as an argument (didn't seem
worthwhile to me).

2) No docs or related regression test yet. I will do that if there is
enough interest in this getting committed. So far no one except Andrew
and I have chimed in.

3) Requires a catalog version bump (not in posted diff)

4) The static function cleanup_path() was borrowed from

src/bin/pg_config/pg_config.c

It is a small and stable function (no change since 2010 AFAICS), so
maybe not worth the effort, but I was wondering if it should be moved
to src/common somewhere and shared.

I will add this to the next commitfest. Comments/feedback encouraged.

Joe

- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV2PykAAoJEDfy90M199hlQW0P/1fLCtFe50wFanleOxo41aki
yR8uG5vUZCLosx7lYd4+LyeE2g+bfs+fK6XgL1qIafI0zyxQSAU8TtjsIPQjjsvU
rNn1MWRrlOLEfOMMzbJPo01w5wzLhBvFzrYQ8vVtvf+T2PzjbU1hTMOcmaeXv6If
jYv0KQDgPBk/VPZ0D7MI4nYXVzNSInDLD7TGEpoTQwZ0oqvZwScSXc933isoULB4
4isael+g6mQJNoPz+OQEhUSoC922mrGs12SarfHJiUqJs1/NleClRRZ/9llCBnb2
3+zW6cb4XNh8aVP33zTtCsbrio206VjumWUYMNs546+qChormBOnYtZiIVRNRnPk
z4x/vxuhXVndDp1VnE5V5mRiW3B8ABliBf1Bcnf/Z+Gxi84LaZVtmL2hJrmn7voT
EZsQn/gmpB6ThHKbOl3t060fGZ/RAPDUwOWoYUIVcohOQqxK/iIka0bFM5cnuXO0
8oJ7CFkPSW7kBPs3uPO4Psf/jzrfaK3b/ZfitoV77sMQiVCABlR3a8khw+cPBrok
av/1afnGfz6qSxsV8sAyKUmRZkLDtmT01GUHCuujof1PQ3tD8zVsQWI3r51UcGB3
tFKvvy9koTHEunqkU6yQrCWNOEzHpGXEa1RIV33Ywgh0deKVEU5EbfJF5iIHBgOy
dYf2PHbYW7F1RSqKnZIa
=A2+X
-----END PGP SIGNATURE-----

On Sun, Aug 23, 2015 at 7:50 AM, Joe Conway <mail@joeconway.com> wrote:

1) The syntax is a bit different than what Andrew proposed:

8<----------------
select setting ~ '--with-libxml' as has_xml
from pg_config
where name = 'CONFIGURE';
has_xml
- ---------
t
(1 row)
8<----------------

In particular note that the name values are all upper case to be
consistent with pg_config, and at least currently there is no version
of the function which accepts a name as an argument (didn't seem
worthwhile to me).

Compatibility by default with the binary pg_config makes sense, users
could just wrap an SQL with lower() or upper() if needed.

2) No docs or related regression test yet. I will do that if there is
enough interest in this getting committed. So far no one except Andrew
and I have chimed in.

I think that's a good thing to have, now I have concerns about making
this data readable for non-superusers. Cloud deployments of Postgres
are logically going to block the access of this view.

4) The static function cleanup_path() was borrowed from

src/bin/pg_config/pg_config.c

cleanup_path is perhaps a candidate for src/port/path.c?

It is a small and stable function (no change since 2010 AFAICS), so
maybe not worth the effort, but I was wondering if it should be moved
to src/common somewhere and shared.

I will add this to the next commitfest. Comments/feedback encouraged.

+ Datum pg_config(PG_FUNCTION_ARGS);
+
+ PG_FUNCTION_INFO_V1(pg_config);

The declaration of the function is not needed, PG_FUNCTION_INFO_V1
takes care of it.
Regards,
--
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 08/23/2015 08:58 PM, Michael Paquier wrote:

2) No docs or related regression test yet. I will do that if there is
enough interest in this getting committed. So far no one except Andrew
and I have chimed in.

I think that's a good thing to have, now I have concerns about making
this data readable for non-superusers. Cloud deployments of Postgres
are logically going to block the access of this view.

I don't think it exposes any information of great security value.

+ Datum pg_config(PG_FUNCTION_ARGS);
+
+ PG_FUNCTION_INFO_V1(pg_config);

The declaration of the function is not needed, PG_FUNCTION_INFO_V1
takes care of it.

Umm, we shouldn't be using PG_FUNCTION_INFO_V1 in backend code at all, IIRC.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:

On 08/23/2015 08:58 PM, Michael Paquier wrote:

I think that's a good thing to have, now I have concerns about making
this data readable for non-superusers. Cloud deployments of Postgres
are logically going to block the access of this view.

I don't think it exposes any information of great security value.

We just had that kerfuffle about whether WAL compression posed a security
risk; doesn't that imply that at least the data relevant to WAL position
has to be unreadable by non-superusers?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/24/2015 06:50 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 08/23/2015 08:58 PM, Michael Paquier wrote:

I think that's a good thing to have, now I have concerns about
making this data readable for non-superusers. Cloud deployments
of Postgres are logically going to block the access of this
view.

I don't think it exposes any information of great security
value.

We just had that kerfuffle about whether WAL compression posed a
security risk; doesn't that imply that at least the data relevant
to WAL position has to be unreadable by non-superusers?

So pg_config might be fully unrestricted, but pg_controldata might
need certain rows filtered based on superuser status? Do you think
those rows should be present but redacted, or completely filtered out?

Joe
- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV2z3SAAoJEDfy90M199hlgmwP/iPI4gJAM00b1mWiPHYSEMjQ
pdVgPkFgfGQKyTizo7rEv1nJTQI3J9aUD7hvqYvPGlSOum0xei17fiRUIKnfqGgZ
7aSuhc97gZ7U5LvDsClovEUDEon+RIibZAYHKnKv2qYDwO/ZvfdFFQNi9TV0eREi
QrEYafNo3/PWqJtrJoqhXaXyXsZ33FKtaaesQZJXvUUkTaE42eviq0cPiz2lHEsq
szlGBnPkBS3qthAusApetAobZH9OymL4yl1BWwmBl3d2nEvQ4OVFGWo195It4XyQ
98bMzXse0PvBuKkcKrlTjxPdtR9UE/2FHojh7VLaj+JQeCGjehXNuogGPr7XHNSu
cbCvIWsxW7Vz1liwFxY9I7Aui6/4X/oPehrct4CqaihqoztP1JrkQpVJDBYWwAhH
Q/sRe8gUY8AWQHQljt9nuZvXmEYBnFbSf8tWVZ3/yhU1fK9dcl9B5doIHwKQXXtW
+BHx4mOX5gcSRvGQFkJO0auE3Y9dvfUtpV4xDC57OHekgKA+rZw/HtElwKIhgrHI
QoCd9PpJdG3UngX7ffsRuhJIhTUCSOKA2AIdceRyH4UgtqtHLzSU1tom3XMcQD+f
mJvlKMwSvqh2Qmd/ZiNhgN4APkGk1AmH26hMMhI9HIrAIghkmPDfssLxYcBgJyDd
lt8dJLQDnaddFLuvdQww
=KZVU
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/24/2015 04:38 AM, Andrew Dunstan wrote:

On 08/23/2015 08:58 PM, Michael Paquier wrote:

+ Datum pg_config(PG_FUNCTION_ARGS); + +
PG_FUNCTION_INFO_V1(pg_config);

The declaration of the function is not needed,
PG_FUNCTION_INFO_V1 takes care of it.

Umm, we shouldn't be using PG_FUNCTION_INFO_V1 in backend code at
all, IIRC.

Right -- those lines are a cut-n-pasteo from the original pg_config as
an extension code. Will fix.

Thanks,

Joe

- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV20DqAAoJEDfy90M199hlA9wP/RtnahsLzmbsXfPssTGUfdHu
nuiF5Sgpqn5/tMNakNVr/ACBiSZQeFUf3FQNRzyoOK6zMXCox4HbSFKi4u0UxpYV
CZZgIKByf4xaHjaZGpnY5dTteBQXdRv3Dp85hhmVbDHbO80+7e7zf0BI5QrUm14E
Nhv6PJn6NMBm/GJrvm76+lDt7DJWYygi/3Jupn/aQNpPCZ5bHP+e4e/NC2FMtW3y
Knm+KN5YEA0IWZKnM0s9kIfYeI9PE2tsF3jpdw8U7BTzziLf/6yTVXlJ/5xj0CfU
1kubgcZTp5UhDOWD7RuRQ6WUzbye/Yd/+9C9SNYltidZY7tnlbRyb0J6QerXNakM
tM+eXAbroXnfAZulq8YJO8nFPviXh6Y4F1pEXtpVJIuLTu9NXEDhRLPAzsSXciCa
yQuq98L2UmzpSr9i5ETMmjb7mUPcS9/IR/FQldNgP1/ARY2CTyL6hbdCJH8QieVo
plEUaYPz4QbKTyF/OZsuamDSpqun412Zs/LRgF5kQhIcI1Q0z9SJ4GwQUZb/bwQm
c0ztQnW8AKtzBgGVCYoJSKd4bD5w/Qtv8WdoZJzXnu3GOvq/laS+kCaBcYl3N7Rf
dwDKpYmWitmyIT0THzhdCiJ38rMgq/JjmhCJQiMJJxvvsadl/mPKUO6k4ZUMNw6O
BKrHf/JETN/Wnqd1IPqq
=ohKC
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/24/2015 08:52 AM, Joe Conway wrote:

On 08/24/2015 06:50 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 08/23/2015 08:58 PM, Michael Paquier wrote:

I think that's a good thing to have, now I have concerns
about making this data readable for non-superusers. Cloud
deployments of Postgres are logically going to block the
access of this view.

I don't think it exposes any information of great security
value.

We just had that kerfuffle about whether WAL compression posed a
security risk; doesn't that imply that at least the data
relevant to WAL position has to be unreadable by non-superusers?

So pg_config might be fully unrestricted, but pg_controldata might
need certain rows filtered based on superuser status? Do you think
those rows should be present but redacted, or completely filtered
out?

Here is the next installment on this. It addresses most of the
previous comments, but does not yet address the issue raised here by Tom
.

Changes:
1.) pg_controldata() function and pg_controldata view added

2.) cleanup_path() moved to port/path.c

3.) extra PG_FUNCTION_INFO_V1() noise removed

Issues needing comment:
a.) Which items need hiding from non-superusers and should the value be
redacted or the entire result set row be suppressed?

b.) There is a difference in the formatting of timestamps between the
pg_controldata binary and the builtin function. To see it do:

  diff -c <(pg_controldata) \
  <(psql -qAt -c "select rpad(name || ':', 38) || setting
                  from pg_controldata")

What I see is:

pg_controldata
! pg_control last modified: Tue 25 Aug 2015 08:10:42 PM PDT
pg_controldata()
! pg_control last modified: Tue Aug 25 20:10:42 2015

Does it matter?

c.) There is some common code between pg_controldata.c in bin and
pg_controldata.c in backend/utils/misc. Specifically the string
definitions in printf statements match those in ControlData[], and
dbState() and wal_level_str() are in both places. Any opinions
on consolidating them in src/common somewhere?

d.) Still no docs yet - will get to it eventually.

Thanks,

Joe

- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3TNnAAoJEDfy90M199hl0OsQAIyTr0hqxwjrGenDpnS4qE8u
UJWVeCpqehFIobxcJ0TICTaQX835fzPGJIiTUwI1Dmz9sgjipvSG1wBmD4bRT93X
WO4e/+Yr5onZ9vNVXlUswPK2kuzehImhmzMSnJ6KDXKkfw2MOZmz56wBb3yIB3lq
K44FDukZ01w9RCGM8H5B/MPNMHIqfBB4wdlKARJZhqeUyPvTJ71iMiqeE77v3AIH
JLmW6kRw8c3NVu/Wa+GVz4FGjIZKR5oazlFYfDTeHXrxV8NIDUFNrKikAW1ScdVK
qSPVjFxoUlbX4W2dd1L1ciGeq83DktYbdKtpZZScQGXwhuq7Y1fHZQwzlxlraB/c
UiqNdxmi7IeUdOIncsKPDmjs7C5yeNj1CRnWHTAQRW98RM42A3TvT2Qlkxm0CVLQ
lZjFVOOMIf4pXYQv6PfiicO6QWYTUSXCa891s/10H2xkS/sMK1yHz3DWSZxVdDdI
dbh5gie/GFro1nwWd8gjkn5KCe917GDBAUBn+QE5TgUPnRhserq6FQBSyVXfZtOQ
o6nRM8vuv9Y06CRoeIgagtDWxippl0OAw442wHyme/PBQZ2842PW8GNNqw+B1HWz
Ir0V5FiZdLLQipwiKT152+8OsOa/NU6wxGFuJr8It/4471h3jU5dxuHO+wQqMDEb
xCn6ebwZaa9oSjHFrfy3
=oMOO
-----END PGP SIGNATURE-----

* Joe Conway (mail@joeconway.com) wrote:

Issues needing comment:
a.) Which items need hiding from non-superusers and should the value be
redacted or the entire result set row be suppressed?

I'm of the opinion that we need to at least redact it and that what we
should do is simply suppress the entire result set until we provide a
way for administrators to manage who can access it (eg: default roles,
this one would fall under 'pg_monitor', imo).

b.) There is a difference in the formatting of timestamps between the
pg_controldata binary and the builtin function. To see it do:

diff -c <(pg_controldata) \
<(psql -qAt -c "select rpad(name || ':', 38) || setting
from pg_controldata")

What I see is:

pg_controldata
! pg_control last modified: Tue 25 Aug 2015 08:10:42 PM PDT
pg_controldata()
! pg_control last modified: Tue Aug 25 20:10:42 2015

Does it matter?

I don't think we can help that, can we? At the least, the
pg_controldata() output should match what the GUCs and whatnot tell us
to do, but the pg_controldata file needs to include things like the
timezone. In the end, I don't believe we need to make them match and
trying to would just make things ugly.

c.) There is some common code between pg_controldata.c in bin and
pg_controldata.c in backend/utils/misc. Specifically the string
definitions in printf statements match those in ControlData[], and
dbState() and wal_level_str() are in both places. Any opinions
on consolidating them in src/common somewhere?

Haven't got any great ideas about exactly how to consolidate them, but I
do think it'd be good to do so..

Thanks!

Stephen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/2015 06:33 AM, Stephen Frost wrote:

* Joe Conway (mail@joeconway.com) wrote:

Issues needing comment: a.) Which items need hiding from
non-superusers and should the value be redacted or the entire
result set row be suppressed?

I'm of the opinion that we need to at least redact it and that what
we should do is simply suppress the entire result set until we
provide a way for administrators to manage who can access it (eg:
default roles, this one would fall under 'pg_monitor', imo).

Whatever it is it would have to be available during initdb. And in any
case I'm no closer to knowing which rows to hide/redact/suppress other
than WAL position. Possibly the thing to do for now would be to revoke
public from these?

Joe
- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3c3nAAoJEDfy90M199hlMnYQAJliTc7bJTCndMQ0emN6xV55
DqODtxABxh3kqPmWcvSO08dSZ5yHpCKYgIm8OmRIpfDUwNID1uBXsO5pRd1XVzLr
42OmQ9QauAZ9+f/Rea668U/zgzhnIJXdVsFfAmum516UoR3W1rqW5ggPKgN5YDhC
9Z6ikL1fs6l6l1yrvaefbepS1FLx6wDplhctN+hbEdHw9gwAf67fv7ncaPZ4BRyc
hogL4mXoz0fFQz7RDvnR2g0uu17k3imbwzqGiyJwH4+9cfnNLWrBXupKwC06ufWF
t3cLh4lLTUhx/2amB0qKMQp1MgVs6r70f5ciFTWvaO0nro0wSGHnIsnqFDOfnv2X
kctZreHs7gDAFXWM4Qp45oxTHy6Lfce75IvDfZGZ3y8NOhEHZDqJs6VIdOgCu4h0
RkJE/RrRz7ZtMAhyokxWMZvffYRutLPbXAUvg6TBeDVy1T7SKoQK81IBz/Nkd+Bm
WkB/EFklUZw/B2HnDpXRV3tdjAzMAJw22bQi0Y7515K25w7NC2nquzX1eBMGmaqe
yDf/gobFg601E9WMjaNoxMGy3Niigk46UsQLGT7RJ/ciojY1gGQh/qd4b1BeJpM0
kRmj0Jsyn0cO8hs6h7jBNBVJjlBhr9ijd4tWaZAk9XqLExPPmGunhcoOMf6ttmvy
533U1P2OKyGBZZissMd4
=dlGD
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Joe Conway (mail@joeconway.com) wrote:

On 08/26/2015 06:33 AM, Stephen Frost wrote:

* Joe Conway (mail@joeconway.com) wrote:

Issues needing comment: a.) Which items need hiding from
non-superusers and should the value be redacted or the entire
result set row be suppressed?

I'm of the opinion that we need to at least redact it and that what
we should do is simply suppress the entire result set until we
provide a way for administrators to manage who can access it (eg:
default roles, this one would fall under 'pg_monitor', imo).

Whatever it is it would have to be available during initdb. And in any
case I'm no closer to knowing which rows to hide/redact/suppress other
than WAL position. Possibly the thing to do for now would be to revoke
public from these?

That was my thinking- revoke public from them. The default roles, based
on the last patch anyway, are available at initdb time and when
system_views.sql is run.

Thanks!

Stehpen

On 8/20/15 9:59 AM, Andrew Dunstan wrote:

The regression tests thus passed, but should not have. It occurred to me
that if we had a test like

select pg_config('configure') ~ '--with-libxml' as has_xml;

in the xml tests then this failure mode would be detected.

This particular case could probably be addressed in a less roundabout
way by enhancing the mapping mechanism in pg_regress.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8/24/15 9:50 AM, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On 08/23/2015 08:58 PM, Michael Paquier wrote:

I think that's a good thing to have, now I have concerns about making
this data readable for non-superusers. Cloud deployments of Postgres
are logically going to block the access of this view.

I don't think it exposes any information of great security value.

We just had that kerfuffle about whether WAL compression posed a security
risk; doesn't that imply that at least the data relevant to WAL position
has to be unreadable by non-superusers?

We already have functions that expose the current (or recent, or
interesting) WAL position, so any new ones should probably follow the
existing ones. Or possibly we don't need any new ones, because we
already have enough?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8/25/15 11:32 PM, Joe Conway wrote:

1.) pg_controldata() function and pg_controldata view added

I don't think dumping out whatever pg_controldata happens to print as a
bunch of text fields is very sophisticated. We have functionality to
compute with WAL positions, for example, and they won't be of much use
if this is going to be all text.

Also, the GUC settings tracked in pg_control can already be viewed using
normal mechanisms, so we don't need a second way to see them.

The fact that some of this is stored in pg_control and some is not is
really an implementation detail. We should be thinking of ways to
expose specific useful information in useful ways, not just dump out
everything we can find. Ultimately, I think we would like to move away
from people parsing textual pg_controldata output, but this proposal is
not moving very far in that direction.

--
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, Aug 31, 2015 at 9:47 PM, Peter Eisentraut <peter_e@gmx.net> wrote:

On 8/25/15 11:32 PM, Joe Conway wrote:

1.) pg_controldata() function and pg_controldata view added

I don't think dumping out whatever pg_controldata happens to print as a
bunch of text fields is very sophisticated. We have functionality to
compute with WAL positions, for example, and they won't be of much use
if this is going to be all text.

Also, the GUC settings tracked in pg_control can already be viewed using
normal mechanisms, so we don't need a second way to see them.

The fact that some of this is stored in pg_control and some is not is
really an implementation detail. We should be thinking of ways to
expose specific useful information in useful ways, not just dump out
everything we can find. Ultimately, I think we would like to move away
from people parsing textual pg_controldata output, but this proposal is
not moving very far in that direction.

The nice thing about dumping the information as text is that you can
return every value in the same universal format: text. There's a lot
to like about that.

But I'm not sure I like the idea of adding a server dependency on the
ability to exec pg_controldata. That seems like it could be
unreliable at best, and a security vulnerability at worst.

--
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 <robertmhaas@gmail.com> writes:

But I'm not sure I like the idea of adding a server dependency on the
ability to exec pg_controldata. That seems like it could be
unreliable at best, and a security vulnerability at worst.

I hadn't been paying attention --- the proposed patch actually depends on
exec'ing pg_controldata? That's horrid! There is no expectation that
that's installed.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/02/2015 05:25 PM, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

But I'm not sure I like the idea of adding a server dependency on
the ability to exec pg_controldata. That seems like it could be
unreliable at best, and a security vulnerability at worst.

I hadn't been paying attention --- the proposed patch actually
depends on exec'ing pg_controldata? That's horrid! There is no
expectation that that's installed.

No it doesn't. I'm confused :-/

Joe

- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV52qoAAoJEDfy90M199hltvwP/3MfUQfPPglhBuY1V3CTzHu9
kTw5tNuGI/244Yc11wLtV07W+3QWXzCNY/fL1JCW5ns51mTfZKfkskNWD0O9fIex
gvK4p/3Z+y344qsdDlzbzw0A/PU05UCq1UlgXCF6nyQJW6cZfaCckbEpZWVK/uV7
aYokIqnIiilWaPu224b6jBOukK7oizEjXevdFBafLbetLJHMx+9k8LMbpPdieAm/
RSk17+N77WQ2zTFHcdz8U1MYAbaokmv155s1vUFgrqOUJGc0r6K+vImKgxOjbbmg
pv2jf7vvUwwjUy7f2iPhWJAKfGCV1m9ovWaXsMYqcF55JwSzvP8B2htUtM4Lr1qF
SsWO7e36bLoH++yAGfKp7oZIhA9r6SR6cwEoCvso3immZ2zhOzbRcw4tI4pE9fhB
P/mEbKFF5BsGHjeslB8RrMQG68DxEwPkaafH4mc1QjKiXNfWPH9ci+pgfSLVphJq
gn+ZuPrReIFhQKyMchcvZVVWJd9Dt02D2lsIzUfBWGXwOTLFVikD6BC6siy5KWmy
xuEGLEfts9E7gPD3qPXxNuY7TCvb+L7R+1C9/M5diiV7rerMUocH/RqrPP6nXHTc
BdfJhzOfU+H+Kt0nbdE8Vjw3BOKT6nqT0kc+le+F/Q1h2XLB63KhaOkFzVW73Rfd
JRRqkyks+eVgEn2I4OKm
=OAms
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

But I'm not sure I like the idea of adding a server dependency on the
ability to exec pg_controldata. That seems like it could be
unreliable at best, and a security vulnerability at worst.

I hadn't been paying attention --- the proposed patch actually depends on
exec'ing pg_controldata? That's horrid! There is no expectation that
that's installed.

No, it doesn't. For the pg_controldata output it processes the
pg_control file directly, and for pg_config it relies on compile-time
CPPFLAGS.

I think trying to duplicate the exact strings isn't too nice an
interface.

--
�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 09/02/2015 02:34 PM, Alvaro Herrera wrote:

Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

But I'm not sure I like the idea of adding a server dependency on the
ability to exec pg_controldata. That seems like it could be
unreliable at best, and a security vulnerability at worst.

I hadn't been paying attention --- the proposed patch actually depends on
exec'ing pg_controldata? That's horrid! There is no expectation that
that's installed.

No, it doesn't. For the pg_controldata output it processes the
pg_control file directly, and for pg_config it relies on compile-time
CPPFLAGS.

I think trying to duplicate the exact strings isn't too nice an
interface.

Well, for pg_controldata, no, but what else would you do for pg_config?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers