pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Don't try to dump RLS policies or security labels for extension 6+ messages / 1 participants [nested] [flat]
* pgsql: Don't try to dump RLS policies or security labels for extension @ 2023-11-13 22:04 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 22:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't try to dump RLS policies or security labels for extension objects. checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and DUMP_COMPONENT_POLICY flags for extension member objects, even though we lack any infrastructure for tracking extensions' initial settings of these properties. This is not OK. The result was that a dump would always include commands to set these properties for extension objects that have them, with at least three negative consequences: 1. The restoring user might not have privilege to set these properties on these objects. 2. The properties might be incorrect/irrelevant for the version of the extension that's installed in the destination database. 3. The dump itself might fail, in the case of RLS properties attached to extension tables that the dumping user lacks privilege to LOCK. (That's because we must get at least AccessShareLock to ensure that we don't fail while trying to decompile the RLS expressions.) When and if somebody cares to invent initial-state infrastructure for extensions' RLS policies and security labels, we could think about finding another way around problem #3. But in the absence of such infrastructure, this whole thing is just wrong and we shouldn't do it. (Note: this applies only to ordinary dumps; binary-upgrade dumps still dump and restore extension member objects separately, with all properties.) Tom Lane and Jacob Champion. Back-patch to all supported branches. Discussion: https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9e08789d4832b5d1f16d7f54e8d9b9b4ad7bd32b Modified Files -------------- src/bin/pg_dump/pg_dump.c | 22 ++++++++-------- src/test/modules/test_pg_dump/t/001_base.pl | 29 +++++++++++++++++++++- .../modules/test_pg_dump/test_pg_dump--1.0.sql | 2 ++ 3 files changed, 42 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to dump RLS policies or security labels for extension @ 2023-11-13 22:04 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 22:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't try to dump RLS policies or security labels for extension objects. checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and DUMP_COMPONENT_POLICY flags for extension member objects, even though we lack any infrastructure for tracking extensions' initial settings of these properties. This is not OK. The result was that a dump would always include commands to set these properties for extension objects that have them, with at least three negative consequences: 1. The restoring user might not have privilege to set these properties on these objects. 2. The properties might be incorrect/irrelevant for the version of the extension that's installed in the destination database. 3. The dump itself might fail, in the case of RLS properties attached to extension tables that the dumping user lacks privilege to LOCK. (That's because we must get at least AccessShareLock to ensure that we don't fail while trying to decompile the RLS expressions.) When and if somebody cares to invent initial-state infrastructure for extensions' RLS policies and security labels, we could think about finding another way around problem #3. But in the absence of such infrastructure, this whole thing is just wrong and we shouldn't do it. (Note: this applies only to ordinary dumps; binary-upgrade dumps still dump and restore extension member objects separately, with all properties.) Tom Lane and Jacob Champion. Back-patch to all supported branches. Discussion: https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a70f2a57f233244c0a780829baf48c624187d456 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 22 ++++++++++-------- src/test/modules/test_pg_dump/t/001_base.pl | 27 ++++++++++++++++++++++ .../modules/test_pg_dump/test_pg_dump--1.0.sql | 2 ++ 3 files changed, 41 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to dump RLS policies or security labels for extension @ 2023-11-13 22:04 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 22:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't try to dump RLS policies or security labels for extension objects. checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and DUMP_COMPONENT_POLICY flags for extension member objects, even though we lack any infrastructure for tracking extensions' initial settings of these properties. This is not OK. The result was that a dump would always include commands to set these properties for extension objects that have them, with at least three negative consequences: 1. The restoring user might not have privilege to set these properties on these objects. 2. The properties might be incorrect/irrelevant for the version of the extension that's installed in the destination database. 3. The dump itself might fail, in the case of RLS properties attached to extension tables that the dumping user lacks privilege to LOCK. (That's because we must get at least AccessShareLock to ensure that we don't fail while trying to decompile the RLS expressions.) When and if somebody cares to invent initial-state infrastructure for extensions' RLS policies and security labels, we could think about finding another way around problem #3. But in the absence of such infrastructure, this whole thing is just wrong and we shouldn't do it. (Note: this applies only to ordinary dumps; binary-upgrade dumps still dump and restore extension member objects separately, with all properties.) Tom Lane and Jacob Champion. Back-patch to all supported branches. Discussion: https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/64d2467fc8d34b2a0c84d1c1aadb349a0df4b618 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 22 ++++++++++-------- src/test/modules/test_pg_dump/t/001_base.pl | 27 ++++++++++++++++++++++ .../modules/test_pg_dump/test_pg_dump--1.0.sql | 2 ++ 3 files changed, 41 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to dump RLS policies or security labels for extension @ 2023-11-13 22:04 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 22:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't try to dump RLS policies or security labels for extension objects. checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and DUMP_COMPONENT_POLICY flags for extension member objects, even though we lack any infrastructure for tracking extensions' initial settings of these properties. This is not OK. The result was that a dump would always include commands to set these properties for extension objects that have them, with at least three negative consequences: 1. The restoring user might not have privilege to set these properties on these objects. 2. The properties might be incorrect/irrelevant for the version of the extension that's installed in the destination database. 3. The dump itself might fail, in the case of RLS properties attached to extension tables that the dumping user lacks privilege to LOCK. (That's because we must get at least AccessShareLock to ensure that we don't fail while trying to decompile the RLS expressions.) When and if somebody cares to invent initial-state infrastructure for extensions' RLS policies and security labels, we could think about finding another way around problem #3. But in the absence of such infrastructure, this whole thing is just wrong and we shouldn't do it. (Note: this applies only to ordinary dumps; binary-upgrade dumps still dump and restore extension member objects separately, with all properties.) Tom Lane and Jacob Champion. Back-patch to all supported branches. Discussion: https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f15147df625fca1466ff3488ced517c239844eef Modified Files -------------- src/bin/pg_dump/pg_dump.c | 22 ++++++++++-------- src/test/modules/test_pg_dump/t/001_base.pl | 27 ++++++++++++++++++++++ .../modules/test_pg_dump/test_pg_dump--1.0.sql | 2 ++ 3 files changed, 41 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to dump RLS policies or security labels for extension @ 2023-11-13 22:04 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 22:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't try to dump RLS policies or security labels for extension objects. checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and DUMP_COMPONENT_POLICY flags for extension member objects, even though we lack any infrastructure for tracking extensions' initial settings of these properties. This is not OK. The result was that a dump would always include commands to set these properties for extension objects that have them, with at least three negative consequences: 1. The restoring user might not have privilege to set these properties on these objects. 2. The properties might be incorrect/irrelevant for the version of the extension that's installed in the destination database. 3. The dump itself might fail, in the case of RLS properties attached to extension tables that the dumping user lacks privilege to LOCK. (That's because we must get at least AccessShareLock to ensure that we don't fail while trying to decompile the RLS expressions.) When and if somebody cares to invent initial-state infrastructure for extensions' RLS policies and security labels, we could think about finding another way around problem #3. But in the absence of such infrastructure, this whole thing is just wrong and we shouldn't do it. (Note: this applies only to ordinary dumps; binary-upgrade dumps still dump and restore extension member objects separately, with all properties.) Tom Lane and Jacob Champion. Back-patch to all supported branches. Discussion: https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/891afa84c27efb2d496540cbc0b5dd1faaec4e91 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 22 ++++++++-------- src/test/modules/test_pg_dump/t/001_base.pl | 29 +++++++++++++++++++++- .../modules/test_pg_dump/test_pg_dump--1.0.sql | 2 ++ 3 files changed, 42 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't try to dump RLS policies or security labels for extension @ 2023-11-13 22:04 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 22:04 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't try to dump RLS policies or security labels for extension objects. checkExtensionMembership() set the DUMP_COMPONENT_SECLABEL and DUMP_COMPONENT_POLICY flags for extension member objects, even though we lack any infrastructure for tracking extensions' initial settings of these properties. This is not OK. The result was that a dump would always include commands to set these properties for extension objects that have them, with at least three negative consequences: 1. The restoring user might not have privilege to set these properties on these objects. 2. The properties might be incorrect/irrelevant for the version of the extension that's installed in the destination database. 3. The dump itself might fail, in the case of RLS properties attached to extension tables that the dumping user lacks privilege to LOCK. (That's because we must get at least AccessShareLock to ensure that we don't fail while trying to decompile the RLS expressions.) When and if somebody cares to invent initial-state infrastructure for extensions' RLS policies and security labels, we could think about finding another way around problem #3. But in the absence of such infrastructure, this whole thing is just wrong and we shouldn't do it. (Note: this applies only to ordinary dumps; binary-upgrade dumps still dump and restore extension member objects separately, with all properties.) Tom Lane and Jacob Champion. Back-patch to all supported branches. Discussion: https://postgr.es/m/00d46a48-3324-d9a0-49bf-e7f0f11d1038@timescale.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/15439205d8cec6fff71e77f0fdd935129120edd0 Modified Files -------------- src/bin/pg_dump/pg_dump.c | 22 ++++++++++-------- src/test/modules/test_pg_dump/t/001_base.pl | 27 ++++++++++++++++++++++ .../modules/test_pg_dump/test_pg_dump--1.0.sql | 2 ++ 3 files changed, 41 insertions(+), 10 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-11-13 22:04 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-11-13 22:04 pgsql: Don't try to dump RLS policies or security labels for extension Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 22:04 pgsql: Don't try to dump RLS policies or security labels for extension Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 22:04 pgsql: Don't try to dump RLS policies or security labels for extension Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 22:04 pgsql: Don't try to dump RLS policies or security labels for extension Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 22:04 pgsql: Don't try to dump RLS policies or security labels for extension Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 22:04 pgsql: Don't try to dump RLS policies or security labels for extension Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox