|
23 | 23 | </para> |
24 | 24 |
|
25 | 25 | <para> |
26 | | - However, see the first two changelog items below, |
27 | | - which describe cases in which reindexing indexes after the upgrade |
28 | | - may be advisable. |
| 26 | + However, see the first changelog item below concerning a possible |
| 27 | + need to update stored views. Also see the third and fourth changelog |
| 28 | + items, which describe cases in which reindexing indexes after the |
| 29 | + upgrade may be advisable. |
29 | 30 | </para> |
30 | 31 | </sect2> |
31 | 32 |
|
|
36 | 37 |
|
37 | 38 | <listitem> |
38 | 39 | <!-- |
| 40 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 41 | +Branch: master [c028faf2a] 2021-02-08 10:14:09 -0500 |
| 42 | +Branch: REL_13_STABLE [d525fbcfd] 2021-02-08 10:14:09 -0500 |
| 43 | +--> |
| 44 | + <para> |
| 45 | + Fix failure to check per-column <literal>SELECT</literal> privileges |
| 46 | + in some join queries (Tom Lane) |
| 47 | + </para> |
| 48 | + |
| 49 | + <para> |
| 50 | + In some cases involving joins, the parser failed to record all the |
| 51 | + columns read by a query in the column-usage bitmaps that are used |
| 52 | + for permissions checking. Although the executor would still insist |
| 53 | + on some sort of <literal>SELECT</literal> privilege to run the |
| 54 | + query, this meant that a user having <literal>SELECT</literal> |
| 55 | + privilege on only one column of a table could nonetheless read all |
| 56 | + its columns through a suitably crafted query. |
| 57 | + </para> |
| 58 | + |
| 59 | + <para> |
| 60 | + A stored view that is subject to this problem will have incomplete |
| 61 | + column-usage bitmaps, and thus permissions will still not be |
| 62 | + enforced properly on the view after updating. In installations that |
| 63 | + depend on column-level permissions for security, it is recommended |
| 64 | + to <command>CREATE OR REPLACE</command> all user-defined views to |
| 65 | + cause them to be re-parsed. |
| 66 | + </para> |
| 67 | + |
| 68 | + <para> |
| 69 | + The <productname>PostgreSQL</productname> Project thanks |
| 70 | + Sven Klemm for reporting this problem. |
| 71 | + (CVE-2021-20229) |
| 72 | + </para> |
| 73 | + </listitem> |
| 74 | + |
| 75 | + <listitem> |
| 76 | +<!-- |
| 77 | +Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> |
| 78 | +Branch: master [6214e2b22] 2021-02-08 11:01:51 +0200 |
| 79 | +Branch: REL_13_STABLE [8e56684d5] 2021-02-08 11:01:55 +0200 |
| 80 | +Branch: REL_12_STABLE [f50e88899] 2021-02-08 11:01:55 +0200 |
| 81 | +Branch: REL_11_STABLE [cb5868cc1] 2021-02-08 11:01:55 +0200 |
| 82 | +--> |
| 83 | + <para> |
| 84 | + Fix information leakage in constraint-violation error messages |
| 85 | + (Heikki Linnakangas) |
| 86 | + </para> |
| 87 | + |
| 88 | + <para> |
| 89 | + If an <command>UPDATE</command> command attempts to move a row to a |
| 90 | + different partition but finds that it violates some constraint on |
| 91 | + the new partition, and the columns in that partition are in |
| 92 | + different physical positions than in the parent table, the error |
| 93 | + message could reveal the contents of columns that the user does not |
| 94 | + have <literal>SELECT</literal> privilege on. |
| 95 | + (CVE-2021-3393) |
| 96 | + </para> |
| 97 | + </listitem> |
| 98 | + |
| 99 | + <listitem> |
| 100 | +<!-- |
39 | 101 | Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> |
40 | 102 | Branch: master [6b4d3046f] 2021-01-20 11:58:03 +0200 |
41 | 103 | Branch: REL_13_STABLE [b8403d140] 2021-01-20 11:58:25 +0200 |
|