|
35 | 35 |
|
36 | 36 | <listitem> |
37 | 37 | <!-- |
| 38 | +Author: Noah Misch <noah@leadboat.com> |
| 39 | +Branch: master [681d9e462] 2023-05-08 06:14:07 -0700 |
| 40 | +Branch: REL_15_STABLE [dbd5795e7] 2023-05-08 06:14:11 -0700 |
| 41 | +Branch: REL_14_STABLE [01e8182c7] 2023-05-08 06:14:11 -0700 |
| 42 | +Branch: REL_13_STABLE [2212f7db8] 2023-05-08 06:14:12 -0700 |
| 43 | +Branch: REL_12_STABLE [78119a0bf] 2023-05-08 06:14:12 -0700 |
| 44 | +Branch: REL_11_STABLE [23cb8eaeb] 2023-05-08 06:14:12 -0700 |
| 45 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 46 | +Branch: master [8d525d7b9] 2023-05-08 11:24:47 -0400 |
| 47 | +Branch: REL_15_STABLE [1b761d896] 2023-05-08 11:24:47 -0400 |
| 48 | +Branch: REL_14_STABLE [1913f63dc] 2023-05-08 11:24:47 -0400 |
| 49 | +Branch: REL_13_STABLE [feb9e7fbb] 2023-05-08 11:24:47 -0400 |
| 50 | +Branch: REL_12_STABLE [2cd843cc9] 2023-05-08 11:24:47 -0400 |
| 51 | +Branch: REL_11_STABLE [766e06140] 2023-05-08 11:24:47 -0400 |
| 52 | +--> |
| 53 | + <para> |
| 54 | + Prevent <command>CREATE SCHEMA</command> from defeating changes |
| 55 | + in <varname>search_path</varname> (Alexander Lakhin) |
| 56 | + </para> |
| 57 | + |
| 58 | + <para> |
| 59 | + Within a <command>CREATE SCHEMA</command> command, objects in the |
| 60 | + prevailing <varname>search_path</varname>, as well as those in the |
| 61 | + newly-created schema, would be visible even within a called |
| 62 | + function or script that attempted to set a |
| 63 | + secure <varname>search_path</varname>. This could allow any user |
| 64 | + having permission to create a schema to hijack the privileges of a |
| 65 | + security definer function or extension script. |
| 66 | + </para> |
| 67 | + |
| 68 | + <para> |
| 69 | + The <productname>PostgreSQL</productname> Project thanks |
| 70 | + Alexander Lakhin for reporting this problem. |
| 71 | + (CVE-2023-2454) |
| 72 | + </para> |
| 73 | + </listitem> |
| 74 | + |
| 75 | + <listitem> |
| 76 | +<!-- |
| 77 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 78 | +Branch: master [ca73753b0] 2023-05-08 10:12:44 -0400 |
| 79 | +Branch: REL_15_STABLE [04e560604] 2023-05-08 10:12:44 -0400 |
| 80 | +Branch: REL_14_STABLE [f8d799eda] 2023-05-08 10:12:44 -0400 |
| 81 | +Branch: REL_13_STABLE [b8e28f04f] 2023-05-08 10:12:44 -0400 |
| 82 | +Branch: REL_12_STABLE [ee87b482c] 2023-05-08 10:12:45 -0400 |
| 83 | +Branch: REL_11_STABLE [473626cf0] 2023-05-08 10:12:45 -0400 |
| 84 | +--> |
| 85 | + <para> |
| 86 | + Enforce row-level security policies correctly after inlining a |
| 87 | + set-returning function (Stephen Frost, Tom Lane) |
| 88 | + </para> |
| 89 | + |
| 90 | + <para> |
| 91 | + If a set-returning SQL-language function refers to a table having |
| 92 | + row-level security policies, and it can be inlined into a calling |
| 93 | + query, those RLS policies would not get enforced properly in some |
| 94 | + cases involving re-using a cached plan under a different role. |
| 95 | + This could allow a user to see or modify rows that should have been |
| 96 | + invisible. |
| 97 | + </para> |
| 98 | + |
| 99 | + <para> |
| 100 | + The <productname>PostgreSQL</productname> Project thanks |
| 101 | + Wolfgang Walther for reporting this problem. |
| 102 | + (CVE-2023-2455) |
| 103 | + </para> |
| 104 | + </listitem> |
| 105 | + |
| 106 | + <listitem> |
| 107 | +<!-- |
38 | 108 | Author: Michael Paquier <michael@paquier.xyz> |
39 | 109 | Branch: master [4dadd660f] 2023-04-28 19:29:12 +0900 |
40 | 110 | Branch: REL_15_STABLE [b9ad73ad2] 2023-04-28 19:29:36 +0900 |
|