23 Commits (5987553fde2cb22b69cf9c7d71a92573b7a3b7c9)

Author	SHA1	Message	Date
Michael Paquier	d3c25ca1bf	sepgsql: Adjust regression expected output ... Oversight in 352ea3a, where support for these subcommands has been added. Per buildfarm member rhinoceros.	2 years ago
Peter Eisentraut	b034ef9b37	Remove gratuitous uses of deprecated SELECT INTO ... CREATE TABLE AS has been preferred over SELECT INTO (outside of ecpg and PL/pgSQL) for a long time. There were still a few uses of SELECT INTO in tests and documentation, some old, some more recent. This changes them to CREATE TABLE AS. Some occurrences in the tests remain where they are specifically testing SELECT INTO parsing or similar. Discussion: https://www.postgresql.org/message-id/flat/96dc0df3-e13a-a85d-d045-d6e2c85218da%40enterprisedb.com	4 years ago
Tom Lane	fc576b7c4f	Fix cache reference leak in contrib/sepgsql. ... fixup_whole_row_references() did the wrong thing with a dropped column, resulting in a commit-time warning about a cache reference leak. I (tgl) added a test case exercising this, but back-patched the test only as far as v10; the patch didn't apply cleanly to 9.6 and it didn't seem worth the trouble to adapt it. The bug is pretty old though, so apply the code change all the way back. Michael Luo, with cosmetic improvements by me Discussion: https://postgr.es/m/BYAPR08MB5606D1453D7F50E2AF4D2FD29AD80@BYAPR08MB5606.namprd08.prod.outlook.com	5 years ago
Joe Conway	4f66c93f61	Update sepgsql to add mandatory access control for TRUNCATE ... Use SELinux "db_table: { truncate }" to check if permission is granted to TRUNCATE. Update example SELinux policy to grant needed permission for TRUNCATE. Add new regression test to demonstrate a positive and negative cases. Test will only be run if the loaded SELinux policy has the "db_table: { truncate }" permission. Makes use of recent commit which added object TRUNCATE hook. Patch by Yuli Khodorkovskiy with minor editorialization by me. Not back-patched because the object TRUNCATE hook was not. Author: Yuli Khodorkovskiy Reviewed-by: Joe Conway Discussion: https://postgr.es/m/CAFL5wJcomybj1Xdw7qWmPJRpGuFukKgNrDb6uVBaCMgYS9dkaA%40mail.gmail.com	6 years ago
Andres Freund	578b229718	Remove WITH OIDS support, change oid catalog column visibility. ... Previously tables declared WITH OIDS, including a significant fraction of the catalog tables, stored the oid column not as a normal column, but as part of the tuple header. This special column was not shown by default, which was somewhat odd, as it's often (consider e.g. pg_class.oid) one of the more important parts of a row. Neither pg_dump nor COPY included the contents of the oid column by default. The fact that the oid column was not an ordinary column necessitated a significant amount of special case code to support oid columns. That already was painful for the existing, but upcoming work aiming to make table storage pluggable, would have required expanding and duplicating that "specialness" significantly. WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0). Remove it. Removing includes: - CREATE TABLE and ALTER TABLE syntax for declaring the table to be WITH OIDS has been removed (WITH (oids[ = true]) will error out) - pg_dump does not support dumping tables declared WITH OIDS and will issue a warning when dumping one (and ignore the oid column). - restoring an pg_dump archive with pg_restore will warn when restoring a table with oid contents (and ignore the oid column) - COPY will refuse to load binary dump that includes oids. - pg_upgrade will error out when encountering tables declared WITH OIDS, they have to be altered to remove the oid column first. - Functionality to access the oid of the last inserted row (like plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed. The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false) for CREATE TABLE) is still supported. While that requires a bit of support code, it seems unnecessary to break applications / dumps that do not use oids, and are explicit about not using them. The biggest user of WITH OID columns was postgres' catalog. This commit changes all 'magic' oid columns to be columns that are normally declared and stored. To reduce unnecessary query breakage all the newly added columns are still named 'oid', even if a table's column naming scheme would indicate 'reloid' or such. This obviously requires adapting a lot code, mostly replacing oid access via HeapTupleGetOid() with access to the underlying Form_pg_*->oid column. The bootstrap process now assigns oids for all oid columns in genbki.pl that do not have an explicit value (starting at the largest oid previously used), only oids assigned later by oids will be above FirstBootstrapObjectId. As the oid column now is a normal column the special bootstrap syntax for oids has been removed. Oids are not automatically assigned during insertion anymore, all backend code explicitly assigns oids with GetNewOidWithIndex(). For the rare case that insertions into the catalog via SQL are called for the new pg_nextoid() function can be used (which only works on catalog tables). The fact that oid columns on system tables are now normal columns means that they will be included in the set of columns expanded by * (i.e. SELECT * FROM pg_class will now include the table's oid, previously it did not). It'd not technically be hard to hide oid column by default, but that'd mean confusing behavior would either have to be carried forward forever, or it'd cause breakage down the line. While it's not unlikely that further adjustments are needed, the scope/invasiveness of the patch makes it worthwhile to get merge this now. It's painful to maintain externally, too complicated to commit after the code code freeze, and a dependency of a number of other patches. Catversion bump, for obvious reasons. Author: Andres Freund, with contributions by John Naylor Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de	7 years ago
Peter Eisentraut	244f1c8907	Fix whitespace	8 years ago
Joe Conway	86fa9b2d1b	Make sepgsql regression tests robust vs. collation differences ... In commit 25542d77, regression test coverage was added to sepgsql for partitioned tables. Unfortunately it was not robust in the face of collation differences, per the buildfarm. Force "C" collation in order to fix that. Discussion: https://postgr.es/m/flat/623bcaae-112e-ced0-8c22-a84f75ae0c53%40joeconway.com	8 years ago
Joe Conway	25542d77dd	Add partitioned table support to sepgsql ... The new partitioned table capability added a new relkind, namely RELKIND_PARTITIONED_TABLE. Update sepgsql to treat this new relkind exactly the same way it does RELKIND_RELATION. In addition, add regression test coverage for partitioned tables. Issue raised by Stephen Frost and initial patch by Mike Palmiotto. Review by Tom Lane and Robert Haas, and editorializing by me. Discussion: https://postgr.es/m/flat/623bcaae-112e-ced0-8c22-a84f75ae0c53%40joeconway.com	8 years ago
Heikki Linnakangas	181bdb90ba	Fix typos in comments. ... Backpatch to all supported versions, where applicable, to make backpatching of future fixes go more smoothly. Josh Soref Discussion: https://www.postgresql.org/message-id/CACZqfqCf+5qRztLPgmmosr-B0Ye4srWzzw_mo4c_8_B_mtjmJQ@mail.gmail.com	9 years ago
Tom Lane	18555b1323	Establish conventions about global object names used in regression tests. ... To ensure that "make installcheck" can be used safely against an existing installation, we need to be careful about what global object names (database, role, and tablespace names) we use; otherwise we might accidentally clobber important objects. There's been a weak consensus that test databases should have names including "regression", and that test role names should start with "regress_", but we didn't have any particular rule about tablespace names; and neither of the other rules was followed with any consistency either. This commit moves us a long way towards having a hard-and-fast rule that regression test databases must have names including "regression", and that test role and tablespace names must start with "regress_". It's not completely there because I did not touch some test cases in rolenames.sql that test creation of special role names like "session_user". That will require some rethinking of exactly what we want to test, whereas the intent of this patch is just to hit all the cases in which the needed renamings are cosmetic. There is no enforcement mechanism in this patch either, but if we don't add one we can expect that the tests will soon be violating the convention again. Again, that's not such a cosmetic change and it will require discussion. (But I did use a quick-hack enforcement patch to find these cases.) Discussion: <16638.1468620817@sss.pgh.pa.us>	9 years ago
Joe Conway	794e2558be	Fix sepgsql regression tests. ... The regression tests for sepgsql were broken by changes in the base distro as-shipped policies. Specifically, definition of unconfined_t in the system default policy was changed to bypass multi-category rules, which the regression test depended on. Fix that by defining a custom privileged domain (sepgsql_regtest_superuser_t) and using it instead of system's unconfined_t domain. The new sepgsql_regtest_superuser_t domain performs almost like the current unconfined_t, but restricted by multi-category policy as the traditional unconfined_t was. The custom policy module is a self defined domain, and so should not be affected by related future system policy changes. However, it still uses the unconfined_u:unconfined_r pair for selinux-user and role. Those definitions have not been changed for several years and seem less risky to rely on than the unconfined_t domain. Additionally, if we define custom user/role, they would need to be manually defined at the operating system level, adding more complexity to an already non-standard and complex regression test. Back-patch to 9.3. The regression tests will need more work before working correctly on 9.2. Starting with 9.2, sepgsql has had dependencies on libselinux versions that are only available on newer distros with the changed set of policies (e.g. RHEL 7.x). On 9.1 sepgsql works fine with the older distros with original policy set (e.g. RHEL 6.x), and on which the existing regression tests work fine. We might want eventually change 9.1 sepgsql regression tests to be more independent from the underlying OS policies, however more work will be needed to make that happen and it is not clear that it is worth the effort. Kohei KaiGai with review by Adam Brightwell and me, commentary by Stephen, Alvaro, Tom, Robert, and others.	10 years ago
Robert Haas	f8a54e936b	sepgsql: Enforce db_procedure:{execute} permission. ... To do this, we add an additional object access hook type, OAT_FUNCTION_EXECUTE. KaiGai Kohei	12 years ago
Robert Haas	e965e6344c	sepgsql: Enforce db_schema:search permission. ... KaiGai Kohei, with comment and doc wordsmithing by me	12 years ago
Robert Haas	0f05840bf4	Allow sepgsql labels to depend on object name. ... The main change here is to call security_compute_create_name_raw() rather than security_compute_create_raw(). This ups the minimum requirement for libselinux from 2.0.99 to 2.1.10, but it looks like most distributions will have picked that up before 9.3 is out. KaiGai Kohei	12 years ago
Robert Haas	1cea9bbb21	sepgsql: Support for new post-ALTER access hook. ... KaiGai Kohei	12 years ago
Alvaro Herrera	f4c4335a4a	Add context info to OAT_POST_CREATE security hook ... ... and have sepgsql use it to determine whether to check permissions during certain operations. Indexes that are being created as a result of REINDEX, for instance, do not need to have their permissions checked; they were already checked when the index was created. Author: KaiGai Kohei, slightly revised by me	13 years ago
Robert Haas	523176cbf1	sepgsql_setcon(). ... This is intended as infrastructure to allow sepgsql to cooperate with connection pooling software, by allowing the effective security label to be set for each new connection. KaiGai Kohei, reviewed by Yeb Havinga.	13 years ago
Robert Haas	e914a144d3	sepgsql DROP support. ... KaiGai Kohei	14 years ago
Robert Haas	e1042a3484	sepgsql: Check CREATE permissions for some object types. ... KaiGai Kohei, reviewed by Dimitri Fontaine and me.	14 years ago
Robert Haas	595a441ae9	Add missing check on invocation of trusted procedures. ... KaiGai Kohei	14 years ago
Robert Haas	87d967f70f	Minor sepgsql regression test fixes.	15 years ago
Robert Haas	c7689ee733	Various sepgsql corrections. ... KaiGai Kohei	15 years ago
Robert Haas	968bc6fac9	sepgsql, an SE-Linux integration for PostgreSQL ... This is still pretty rough - among other things, the documentation needs work, and the messages need a visit from the style police - but this gets the basic framework in place. KaiGai Kohei	15 years ago