-
- Downloads
Remove the row_security=force GUC value.
Every query of a single ENABLE ROW SECURITY table has two meanings, with the row_security GUC selecting between them. With row_security=force available, every function author would have been advised to either set the GUC locally or test both meanings. Non-compliance would have threatened reliability and, for SECURITY DEFINER functions, security. Authors already face an obligation to account for search_path, and we should not mimic that example. With this change, only BYPASSRLS roles need exercise the aforementioned care. Back-patch to 9.5, where the row_security GUC was introduced. Since this narrows the domain of pg_db_role_setting.setconfig and pg_proc.proconfig, one might bump catversion. A row_security=force setting in one of those columns will elicit a clear message, so don't.
Showing
- doc/src/sgml/config.sgml 2 additions, 11 deletionsdoc/src/sgml/config.sgml
- doc/src/sgml/ddl.sgml 7 additions, 10 deletionsdoc/src/sgml/ddl.sgml
- src/backend/utils/misc/guc.c 10 additions, 29 deletionssrc/backend/utils/misc/guc.c
- src/backend/utils/misc/rls.c 8 additions, 21 deletionssrc/backend/utils/misc/rls.c
- src/include/utils/plancache.h 1 addition, 1 deletionsrc/include/utils/plancache.h
- src/include/utils/rls.h 2 additions, 10 deletionssrc/include/utils/rls.h
- src/test/regress/expected/rowsecurity.out 2 additions, 109 deletionssrc/test/regress/expected/rowsecurity.out
- src/test/regress/sql/rowsecurity.sql 2 additions, 50 deletionssrc/test/regress/sql/rowsecurity.sql
Loading
Please register or sign in to comment