pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix bugs in manipulation of large objects. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix bugs in manipulation of large objects. @ 2023-12-15 18:55 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-15 18:55 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership info is actually stored (LargeObjectMetadataRelationId). This resulted in failures such as "unrecognized class ID: 2613" when trying to update blob properties as a non-superuser. Poking around for related bugs, I found that AlterObjectOwner_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying it around it should be less wrong. These bugs are quite old. In HEAD, we can reduce the scope for future bugs of this ilk by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/59bd34c2fa02b005dc33190245b2bffc6a08c0b9 Modified Files -------------- src/backend/catalog/aclchk.c | 10 ++++-- src/backend/catalog/pg_shdepend.c | 17 ++-------- src/backend/commands/alter.c | 48 +++++++++++++---------------- src/backend/libpq/be-fsstubs.c | 4 +-- src/backend/storage/large_object/inv_api.c | 9 +++--- src/include/commands/alter.h | 3 +- src/test/regress/expected/largeobject.out | 5 ++- src/test/regress/expected/largeobject_1.out | 5 ++- src/test/regress/sql/largeobject.sql | 8 ++++- 9 files changed, 54 insertions(+), 55 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix bugs in manipulation of large objects. @ 2023-12-15 18:55 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-15 18:55 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership info is actually stored (LargeObjectMetadataRelationId). This resulted in failures such as "unrecognized class ID: 2613" when trying to update blob properties as a non-superuser. Poking around for related bugs, I found that AlterObjectOwner_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying it around it should be less wrong. These bugs are quite old. In HEAD, we can reduce the scope for future bugs of this ilk by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/152bfc0af89de25400abe49205f1d9861a199b61 Modified Files -------------- src/backend/catalog/aclchk.c | 10 +++++++--- src/backend/catalog/pg_shdepend.c | 4 ++++ src/backend/commands/alter.c | 22 ++++++++++++++++++---- src/backend/libpq/be-fsstubs.c | 4 ++-- src/backend/storage/large_object/inv_api.c | 9 ++++----- src/test/regress/expected/largeobject.out | 5 ++++- src/test/regress/expected/largeobject_1.out | 5 ++++- src/test/regress/sql/largeobject.sql | 8 +++++++- 8 files changed, 50 insertions(+), 17 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix bugs in manipulation of large objects. @ 2023-12-15 18:55 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-15 18:55 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership info is actually stored (LargeObjectMetadataRelationId). This resulted in failures such as "unrecognized class ID: 2613" when trying to update blob properties as a non-superuser. Poking around for related bugs, I found that AlterObjectOwner_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying it around it should be less wrong. These bugs are quite old. In HEAD, we can reduce the scope for future bugs of this ilk by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7a99fb6e1377e86afb7c19eb58a1b02d49dc9294 Modified Files -------------- src/backend/catalog/aclchk.c | 4 ++-- src/backend/commands/alter.c | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix bugs in manipulation of large objects. @ 2023-12-15 18:55 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-15 18:55 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership info is actually stored (LargeObjectMetadataRelationId). This resulted in failures such as "unrecognized class ID: 2613" when trying to update blob properties as a non-superuser. Poking around for related bugs, I found that AlterObjectOwner_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying it around it should be less wrong. These bugs are quite old. In HEAD, we can reduce the scope for future bugs of this ilk by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f552f2be2410632f59effffe8ba736c523de6b4c Modified Files -------------- src/backend/catalog/aclchk.c | 4 ++-- src/backend/commands/alter.c | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix bugs in manipulation of large objects. @ 2023-12-15 18:55 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-15 18:55 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership info is actually stored (LargeObjectMetadataRelationId). This resulted in failures such as "unrecognized class ID: 2613" when trying to update blob properties as a non-superuser. Poking around for related bugs, I found that AlterObjectOwner_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying it around it should be less wrong. These bugs are quite old. In HEAD, we can reduce the scope for future bugs of this ilk by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/55b5c67da00f04ab9a72ba4e94c36770b339884e Modified Files -------------- src/backend/catalog/aclchk.c | 4 ++-- src/backend/commands/alter.c | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix bugs in manipulation of large objects. @ 2023-12-15 18:55 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-12-15 18:55 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership info is actually stored (LargeObjectMetadataRelationId). This resulted in failures such as "unrecognized class ID: 2613" when trying to update blob properties as a non-superuser. Poking around for related bugs, I found that AlterObjectOwner_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying it around it should be less wrong. These bugs are quite old. In HEAD, we can reduce the scope for future bugs of this ilk by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ba66f253362a1797bec9641570a02574a65b3a93 Modified Files -------------- src/backend/catalog/aclchk.c | 4 ++-- src/backend/commands/alter.c | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-12-15 18:55 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-12-15 18:55 pgsql: Fix bugs in manipulation of large objects. Tom Lane <tgl@sss.pgh.pa.us> 2023-12-15 18:55 pgsql: Fix bugs in manipulation of large objects. Tom Lane <tgl@sss.pgh.pa.us> 2023-12-15 18:55 pgsql: Fix bugs in manipulation of large objects. Tom Lane <tgl@sss.pgh.pa.us> 2023-12-15 18:55 pgsql: Fix bugs in manipulation of large objects. Tom Lane <tgl@sss.pgh.pa.us> 2023-12-15 18:55 pgsql: Fix bugs in manipulation of large objects. Tom Lane <tgl@sss.pgh.pa.us> 2023-12-15 18:55 pgsql: Fix bugs in manipulation of large objects. 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