From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Multivariate MCV stats can leak data to unprivileged users |
Date: | 2019-05-10 09:19:44 |
Message-ID: | CAEZATCUhT9rt7Ui=Vdx4N==VV5XOK5dsXfnGgVOz_JhAicB=ZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While working on 1aebfbea83c, I noticed that the new multivariate MCV
stats feature suffers from the same problem, and also the original
problems that were fixed in e2d4ef8de8 and earlier --- namely that a
user can see values in the MCV lists that they shouldn't see (values
from tables that they don't have privileges on).
I think there are 2 separate issues here:
1). The table pg_statistic_ext is accessible to anyone, so any user
can see the MCV lists of any table. I think we should give this the
same treatment as pg_statistic, and hide it behind a security barrier
view, revoking public access from the table.
2). The multivariate MCV stats planner code can be made to invoke
user-defined operators, so a user can create a leaky operator and use
it to reveal data values from the MCV lists even if they have no
permissions on the table.
Attached is a draft patch to fix (2), which hooks into
statext_is_compatible_clause().
I haven't thought much about (1). There are some questions about what
exactly the view should look like. Probably it should translate table
oids to names, like pg_stats does, but should it also translate column
indexes to names? That could get fiddly. Should it unpack MCV items?
I'll raise this as an open item for PG12.
Regards,
Dean
Attachment | Content-Type | Size |
---|---|---|
fix-mcv-stats-planner-leak.patch | text/x-patch | 10.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-05-10 10:24:47 | Re: Bug in reindexdb's error reporting |
Previous Message | Julien Rouhaud | 2019-05-10 09:02:52 | Bug in reindexdb's error reporting |