On Mon, Jan 18, 2016 at 4:43 AM, Andres Freund <and...@anarazel.de> wrote: > On 2016-01-18 10:18:34 +0900, Michael Paquier wrote: >> We are trying to hide away from non-superusers WAL-related information >> in system views and system function, that's my point to do the same >> here. > > We are? pg_current_xlog_insert_location(), pg_current_xlog_location(), > pg_is_xlog_replay_paused(), pg_stat_bgwriter ... are all non-superuser?
Yeah. There's certainly no need for the WAL positions reported by pg_controldata to be any more restricted than other functions that give away information about WAL position. We had some discussion about restricting WAL position information in general due to possible information leakage, and if we do that, then perhaps this should be similarly restricted. Presumably vulnerabilities here would be harder to exploit because the values change much less frequently, so if you are trying to learn something the rate at which you can glean information will be much lower. But maybe we should put the same restrictions on all of it. >> For the data of pg_control, it seems to me that this can give >> away to any authorized users hints regarding the way Postgres is >> built, perhaps letting people know for example which Linux >> distribution is used and which flavor of Postgres is used (we already >> give away some information with version() but that's different than >> the libraries this is linking to), so an attacker may be able to take >> advantage of that to do attacks on potentially outdated packages? And >> I would think that many users are actually going to revoke the access >> of those functions to public if we are going to make them >> world-visible. It is easier as well to restrict things first, and then >> relax if necessary, than the opposite as well. > > Meh, that seems pretty far into pseudo security arguments. Yeah, I really don't see anything in the pg_controldata output that looks sensitive. The WAL locations are the closest of anything, AFAICS. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers