2005-07-07 22:40:02 +02:00
|
|
|
--
|
|
|
|
-- DEPENDENCIES
|
|
|
|
--
|
|
|
|
CREATE USER regression_user;
|
|
|
|
CREATE USER regression_user2;
|
|
|
|
CREATE USER regression_user3;
|
|
|
|
CREATE GROUP regression_group;
|
2005-08-04 03:09:29 +02:00
|
|
|
CREATE TABLE deptest (f1 serial primary key, f2 text);
|
2005-07-07 22:40:02 +02:00
|
|
|
GRANT SELECT ON TABLE deptest TO GROUP regression_group;
|
|
|
|
GRANT ALL ON TABLE deptest TO regression_user, regression_user2;
|
|
|
|
-- can't drop neither because they have privileges somewhere
|
|
|
|
DROP USER regression_user;
|
|
|
|
ERROR: role "regression_user" cannot be dropped because some objects depend on it
|
2010-08-26 21:49:08 +02:00
|
|
|
DETAIL: privileges for table deptest
|
2005-07-07 22:40:02 +02:00
|
|
|
DROP GROUP regression_group;
|
|
|
|
ERROR: role "regression_group" cannot be dropped because some objects depend on it
|
2010-08-26 21:49:08 +02:00
|
|
|
DETAIL: privileges for table deptest
|
2005-07-07 22:40:02 +02:00
|
|
|
-- if we revoke the privileges we can drop the group
|
|
|
|
REVOKE SELECT ON deptest FROM GROUP regression_group;
|
|
|
|
DROP GROUP regression_group;
|
|
|
|
-- can't drop the user if we revoke the privileges partially
|
2008-09-08 02:47:41 +02:00
|
|
|
REVOKE SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES ON deptest FROM regression_user;
|
2005-07-07 22:40:02 +02:00
|
|
|
DROP USER regression_user;
|
|
|
|
ERROR: role "regression_user" cannot be dropped because some objects depend on it
|
2010-08-26 21:49:08 +02:00
|
|
|
DETAIL: privileges for table deptest
|
2005-07-07 22:40:02 +02:00
|
|
|
-- now we are OK to drop him
|
|
|
|
REVOKE TRIGGER ON deptest FROM regression_user;
|
|
|
|
DROP USER regression_user;
|
|
|
|
-- we are OK too if we drop the privileges all at once
|
|
|
|
REVOKE ALL ON deptest FROM regression_user2;
|
|
|
|
DROP USER regression_user2;
|
|
|
|
-- can't drop the owner of an object
|
2005-08-04 03:09:29 +02:00
|
|
|
-- the error message detail here would include a pg_toast_nnn name that
|
|
|
|
-- is not constant, so suppress it
|
|
|
|
\set VERBOSITY terse
|
2005-07-07 22:40:02 +02:00
|
|
|
ALTER TABLE deptest OWNER TO regression_user3;
|
|
|
|
DROP USER regression_user3;
|
|
|
|
ERROR: role "regression_user3" cannot be dropped because some objects depend on it
|
2005-11-21 13:49:33 +01:00
|
|
|
\set VERBOSITY default
|
2005-07-07 22:40:02 +02:00
|
|
|
-- if we drop the object, we can drop the user too
|
|
|
|
DROP TABLE deptest;
|
|
|
|
DROP USER regression_user3;
|
2005-11-21 13:49:33 +01:00
|
|
|
-- Test DROP OWNED
|
|
|
|
CREATE USER regression_user0;
|
|
|
|
CREATE USER regression_user1;
|
|
|
|
CREATE USER regression_user2;
|
|
|
|
SET SESSION AUTHORIZATION regression_user0;
|
|
|
|
-- permission denied
|
|
|
|
DROP OWNED BY regression_user1;
|
|
|
|
ERROR: permission denied to drop objects
|
|
|
|
DROP OWNED BY regression_user0, regression_user2;
|
|
|
|
ERROR: permission denied to drop objects
|
|
|
|
REASSIGN OWNED BY regression_user0 TO regression_user1;
|
|
|
|
ERROR: permission denied to reassign objects
|
|
|
|
REASSIGN OWNED BY regression_user1 TO regression_user0;
|
|
|
|
ERROR: permission denied to reassign objects
|
|
|
|
-- this one is allowed
|
|
|
|
DROP OWNED BY regression_user0;
|
2006-08-21 02:57:26 +02:00
|
|
|
CREATE TABLE deptest1 (f1 int unique);
|
2005-11-21 13:49:33 +01:00
|
|
|
GRANT ALL ON deptest1 TO regression_user1 WITH GRANT OPTION;
|
|
|
|
SET SESSION AUTHORIZATION regression_user1;
|
|
|
|
CREATE TABLE deptest (a serial primary key, b text);
|
|
|
|
GRANT ALL ON deptest1 TO regression_user2;
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
\z deptest1
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
Access privileges
|
|
|
|
Schema | Name | Type | Access privileges | Column privileges | Policies
|
|
|
|
--------+----------+-------+--------------------------------------------------+-------------------+----------
|
|
|
|
public | deptest1 | table | regression_user0=arwdDxt/regression_user0 +| |
|
|
|
|
| | | regression_user1=a*r*w*d*D*x*t*/regression_user0+| |
|
|
|
|
| | | regression_user2=arwdDxt/regression_user1 | |
|
2005-11-21 13:49:33 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DROP OWNED BY regression_user1;
|
|
|
|
-- all grants revoked
|
|
|
|
\z deptest1
|
Row-Level Security Policies (RLS)
Building on the updatable security-barrier views work, add the
ability to define policies on tables to limit the set of rows
which are returned from a query and which are allowed to be added
to a table. Expressions defined by the policy for filtering are
added to the security barrier quals of the query, while expressions
defined to check records being added to a table are added to the
with-check options of the query.
New top-level commands are CREATE/ALTER/DROP POLICY and are
controlled by the table owner. Row Security is able to be enabled
and disabled by the owner on a per-table basis using
ALTER TABLE .. ENABLE/DISABLE ROW SECURITY.
Per discussion, ROW SECURITY is disabled on tables by default and
must be enabled for policies on the table to be used. If no
policies exist on a table with ROW SECURITY enabled, a default-deny
policy is used and no records will be visible.
By default, row security is applied at all times except for the
table owner and the superuser. A new GUC, row_security, is added
which can be set to ON, OFF, or FORCE. When set to FORCE, row
security will be applied even for the table owner and superusers.
When set to OFF, row security will be disabled when allowed and an
error will be thrown if the user does not have rights to bypass row
security.
Per discussion, pg_dump sets row_security = OFF by default to ensure
that exports and backups will have all data in the table or will
error if there are insufficient privileges to bypass row security.
A new option has been added to pg_dump, --enable-row-security, to
ask pg_dump to export with row security enabled.
A new role capability, BYPASSRLS, which can only be set by the
superuser, is added to allow other users to be able to bypass row
security using row_security = OFF.
Many thanks to the various individuals who have helped with the
design, particularly Robert Haas for his feedback.
Authors include Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean
Rasheed, with additional changes and rework by me.
Reviewers have included all of the above, Greg Smith,
Jeff McCormick, and Robert Haas.
2014-09-19 17:18:35 +02:00
|
|
|
Access privileges
|
|
|
|
Schema | Name | Type | Access privileges | Column privileges | Policies
|
|
|
|
--------+----------+-------+-------------------------------------------+-------------------+----------
|
|
|
|
public | deptest1 | table | regression_user0=arwdDxt/regression_user0 | |
|
2005-11-21 13:49:33 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- table was dropped
|
|
|
|
\d deptest
|
|
|
|
-- Test REASSIGN OWNED
|
|
|
|
GRANT ALL ON deptest1 TO regression_user1;
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
GRANT CREATE ON DATABASE regression TO regression_user1;
|
2005-11-21 13:49:33 +01:00
|
|
|
SET SESSION AUTHORIZATION regression_user1;
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
CREATE SCHEMA deptest;
|
2005-11-21 13:49:33 +01:00
|
|
|
CREATE TABLE deptest (a serial primary key, b text);
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
ALTER DEFAULT PRIVILEGES FOR ROLE regression_user1 IN SCHEMA deptest
|
|
|
|
GRANT ALL ON TABLES TO regression_user2;
|
|
|
|
CREATE FUNCTION deptest_func() RETURNS void LANGUAGE plpgsql
|
|
|
|
AS $$ BEGIN END; $$;
|
|
|
|
CREATE TYPE deptest_enum AS ENUM ('red');
|
|
|
|
CREATE TYPE deptest_range AS RANGE (SUBTYPE = int4);
|
2006-08-21 02:57:26 +02:00
|
|
|
CREATE TABLE deptest2 (f1 int);
|
|
|
|
-- make a serial column the hard way
|
|
|
|
CREATE SEQUENCE ss1;
|
|
|
|
ALTER TABLE deptest2 ALTER f1 SET DEFAULT nextval('ss1');
|
|
|
|
ALTER SEQUENCE ss1 OWNED BY deptest2.f1;
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
-- When reassigning ownership of a composite type, its pg_class entry
|
|
|
|
-- should match
|
|
|
|
CREATE TYPE deptest_t AS (a int);
|
|
|
|
SELECT typowner = relowner
|
|
|
|
FROM pg_type JOIN pg_class c ON typrelid = c.oid WHERE typname = 'deptest_t';
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
REASSIGN OWNED BY regression_user1 TO regression_user2;
|
|
|
|
\dt deptest
|
|
|
|
List of relations
|
|
|
|
Schema | Name | Type | Owner
|
|
|
|
--------+---------+-------+------------------
|
|
|
|
public | deptest | table | regression_user2
|
|
|
|
(1 row)
|
|
|
|
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
SELECT typowner = relowner
|
|
|
|
FROM pg_type JOIN pg_class c ON typrelid = c.oid WHERE typname = 'deptest_t';
|
|
|
|
?column?
|
|
|
|
----------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
2005-11-21 13:49:33 +01:00
|
|
|
-- doesn't work: grant still exists
|
|
|
|
DROP USER regression_user1;
|
|
|
|
ERROR: role "regression_user1" cannot be dropped because some objects depend on it
|
Rework internals of changing a type's ownership
This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite. Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.
To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly. AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.
I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised. Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.
Per bug #13666 reported by Chris Pacejo.
Backpatch to 9.5.
(I would back-patch this all the way back, except that it doesn't apply
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched. If we
decide that we need this in earlier branches too, we should backpatch
both.)
2015-12-17 18:25:41 +01:00
|
|
|
DETAIL: owner of default privileges on new relations belonging to role regression_user1 in schema deptest
|
|
|
|
privileges for database regression
|
|
|
|
privileges for table deptest1
|
2005-11-21 13:49:33 +01:00
|
|
|
DROP OWNED BY regression_user1;
|
|
|
|
DROP USER regression_user1;
|
|
|
|
\set VERBOSITY terse
|
|
|
|
DROP USER regression_user2;
|
|
|
|
ERROR: role "regression_user2" cannot be dropped because some objects depend on it
|
|
|
|
DROP OWNED BY regression_user2, regression_user0;
|
|
|
|
DROP USER regression_user2;
|
|
|
|
DROP USER regression_user0;
|