Обсуждение: pgsql: Plug RLS related information leak in pg_stats view.

Plug RLS related information leak in pg_stats view.

The pg_stats view is supposed to be restricted to only show rows
about tables the user can read. However, it sometimes can leak
information which could not otherwise be seen when row level security
is enabled. Fix that by not showing pg_stats rows to users that would
be subject to RLS on the table the row is related to. This is done
by creating/using the newly introduced SQL visible function,
row_security_active().

Along the way, clean up three call sites of check_enable_rls(). The second
argument of that function should only be specified as other than
InvalidOid when we are checking as a different user than the current one,
as in when querying through a view. These sites were passing GetUserId()
instead of InvalidOid, which can cause the function to return incorrect
results if the current user has the BYPASSRLS privilege and row_security
has been set to OFF.

Additionally fix a bug causing RI Trigger error messages to unintentionally
leak information when RLS is enabled, and other minor cleanup and
improvements. Also add WITH (security_barrier) to the definition of pg_stats.

Bumped CATVERSION due to new SQL functions and pg_stats view definition.

Back-patch to 9.5 where RLS was introduced. Reported by Yaroslav.
Patch by Joe Conway and Dean Rasheed with review and input by
Michael Paquier and Stephen Frost.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/7b4bfc87d5e73c94ae1591c482f626a011498915

Modified Files
--------------
doc/src/sgml/func.sgml                    |   16 +++++++++
src/backend/access/index/genam.c          |    2 +-
src/backend/catalog/system_views.sql      |    6 ++--
src/backend/executor/execMain.c           |    2 +-
src/backend/rewrite/rowsecurity.c         |   16 ++-------
src/backend/utils/adt/ri_triggers.c       |    4 ++-
src/backend/utils/cache/plancache.c       |    7 +---
src/backend/utils/init/miscinit.c         |   14 +++++++-
src/backend/utils/misc/rls.c              |   53 ++++++++++++++++++++++++++++-
src/include/catalog/catversion.h          |    2 +-
src/include/catalog/pg_proc.h             |    6 ++++
src/include/miscadmin.h                   |    1 +
src/include/utils/builtins.h              |    4 +++
src/test/regress/expected/rowsecurity.out |   38 +++++++++++++++++++--
src/test/regress/expected/rules.out       |    2 +-
src/test/regress/sql/rowsecurity.sql      |   17 ++++++++-
16 files changed, 159 insertions(+), 31 deletions(-)

Joe Conway <mail@joeconway.com> writes:
> Plug RLS related information leak in pg_stats view.

BTW, a note about this: I see you bumped catversion in both branches,
which is good, but you bumped it to the same thing, which I think is
bad.  Two branches with different initial catalog contents should
not have identical catversions; that more or less defeats the point
of having the version number.

What I've done in such cases is to assign yyyymmdd1 to the back
branch and yyyymmdd2 to HEAD.

            regards, tom lane

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

On 07/28/2015 01:56 PM, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> Plug RLS related information leak in pg_stats view.
>
> BTW, a note about this: I see you bumped catversion in both
> branches, which is good, but you bumped it to the same thing, which
> I think is bad.  Two branches with different initial catalog
> contents should not have identical catversions; that more or less
> defeats the point of having the version number.
>
> What I've done in such cases is to assign yyyymmdd1 to the back
> branch and yyyymmdd2 to HEAD.

Ok -- good point. I'll bump HEAD


- --
Joe Conway
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVt+zfAAoJEDfy90M199hl5t4P/36ZHW4MMzwXVWU6SgrKDrI9
+6PTpKdigH85OvpMYoiiU5bITz6E2hHAVGkqHbCLwacQiEiZzRPEV3RSAXCCq5Gn
9ARHurQyb89N8wS3f030gRtXEDbY+f8aUpB9DlZuzUPqD2D1XsIgYKm1jTVFRcT/
7/iXiLQ5lLYNgOcrZVS89THOjcm+IdwGoSm16J6Kd8cte9qmhbeJuLn7poQGXl9D
TwMX6UVWqxufFWD6IGodbpnOw3frYrGTIKSbLMTnj4YaY0hs284xa8ogIGZ4+Tze
FSCDkyh8u5g0VD1uS7ose4hI18VOiO+KNUvzONg/rtuYymR96jCKK49FgjQfE3ud
zsOdsicr8Lx3Z14mWFNJmLtqvtiJ2Px9tCxVuxXb1JNI+kuwJoyBrVh0eNjEeJuS
S38H5OVieYGkhTG6ZFm3aGDUkMY3OWgpwPyncWq0mN0eyYReEBRGn3BD48G7mg2Z
BqhoDMeLvOP0qwwYUDutJk3Y2dPvah8VUQFMjqpWnQEcm7M0FCagkMC6pDKUppFL
Z8L3JmRNLdiF2cxCNc3EyELvWjDhr24mlhT2pjZQKWLlUiMJh0w3omfdwQB0g4qo
g2Yr/BG2D3rgzDiQLmR3DkNyP7Wy9PgQhUmWAnjzqHgfnsclWMQS1blIZhfyeIUk
Mm3RnJ2nTES55pP4KDOi
=4Okg
-----END PGP SIGNATURE-----