I have been looking for this for years and I have tried everything on the web with no success.
I am able to do it in MSSQL, but I didn´t find a way to do it in PostgreSQL.
What I want to achieve is just create a role with login that cannot create, drop or alter databases, functions, tables or anything else. Just select specific functions.
For example, if I have a table called costumer and two functions called return_customers() and return_time() I just want a role with login that are able to select return_customers() and select return_time(). Nothing more than that.
Thank you very much for supporting this useful web site!
Execute this connected to the database you want to configure.
-- Create the user.
CREATE ROLE somebody WITH LOGIN PASSWORD '...';
-- Prevent all authenticated users from being able to use the database,
-- unless they have been explicitly granted permission.
REVOKE ALL PRIVILEGES ON DATABASE foo FROM PUBLIC;
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM PUBLIC;
REVOKE ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM PUBLIC;
-- Allow the user to only use the specified functions.
GRANT CONNECT ON DATABASE foo TO somebody;
GRANT EXECUTE ON FUNCTION return_customers(), return_time() TO somebody;
If you have more schemas than "public" then you will need to add those to the two REVOKE ALL PRIVILEGES ON ALL ... statements.
Do not forget that the functions must have been created with SECURITY DEFINER or this user will still be unable to execute them, as the contents of the function will be executed with the permissions of this user, instead of the user who created the function.
See:
CREATE FUNCTION particularly SECURITY DEFINER
GRANT both for adding users to roles and for assigning access rights to tables, sequences, etc
REVOKE
CREATE ROLE
Related
I am the admin of a PostgreSQL 11 DB on Azure.
Some of the users only have access to specific views.
The users were created by:
CREATE USER M1234 WITH PASSWORD '1234!';
GRANT USAGE ON SCHEMA public TO M1234;
GRANT SELECT ON table v_xxx TO M1234;
GRANT SELECT ON table v_yyy TO M1234;
For some reason the grant for select on one or all the existing views is removed every so often and the users of course cannot access.
I would really appreciate it if anyone has any insight as to why and how this could happen and if there is a more long term solution.
You grant SELECT on existing tables, but for future tables, you need additional permissions
-- Grant access to future tables ALTER DEFAULT PRIVILEGES IN SCHEMA a_given_schema GRANT SELECT ON TABLES TO read access;
I am experiencing a weird and (to me) inexplicable behaviour related to DEFAULT PRIVILEGES. It seems default privileges cannot be revoked just for a specific schema once they have been granted database-wide.
I am currently testing this with PostgreSQL 10.5 on CentOS.
Let's say there are 3 users:
admin Owner of the database. Used to manipulate the STRUCTURE of the database (CREATE, DROP, TRUNCATE...)
manager Used for DATA manipulation (INSERT, UPDATE, DELETE)
reader Used to read DATA (basically SELECT)
The idea is that:
admin will be the owner of the database and all the objects contained into it
manager will be used for data manipulation across all schemas but public (only user admin can modify data in public schema)
reader will be able to read everything.
To make things easier, this will rely on default privileges, so that newly created objects (schemas, tables, views, functions, etc.) will all have the correct permissions.
This is the first time I am trying something like that instead of a fine-grained permissions policy based on multiple users for all different schemas and apparently this setup should be very straightforward.
It turns out I am missing something.
Here is a simple test script. User admin is the owner of db database and all those commands are issued being connected to it as admin:
-- 1. User manager inherits from user "reader"
GRANT reader TO manager;
-- 2. Allow connections to the database to our users, but not PUBLIC
REVOKE ALL ON DATABASE db FROM PUBLIC;
GRANT CONNECT ON DATABASE db TO reader;
-- 3. Revoke default privileges from PUBLIC
ALTER DEFAULT PRIVILEGES REVOKE ALL ON SCHEMAS FROM PUBLIC;
ALTER DEFAULT PRIVILEGES REVOKE ALL ON TABLES FROM PUBLIC;
ALTER DEFAULT PRIVILEGES REVOKE ALL ON SEQUENCES FROM PUBLIC;
ALTER DEFAULT PRIVILEGES REVOKE ALL ON FUNCTIONS FROM PUBLIC;
-- 4. Grant default reading privileges to user "reader"
ALTER DEFAULT PRIVILEGES GRANT USAGE ON SCHEMAS TO reader;
ALTER DEFAULT PRIVILEGES GRANT SELECT ON TABLES TO reader;
ALTER DEFAULT PRIVILEGES GRANT SELECT ON SEQUENCES TO reader;
ALTER DEFAULT PRIVILEGES GRANT EXECUTE ON FUNCTIONS TO reader;
-- 5. Grant Defauly writing privileges to user "manager"
ALTER DEFAULT PRIVILEGES GRANT INSERT, UPDATE, DELETE ON TABLES TO manager;
ALTER DEFAULT PRIVILEGES GRANT USAGE ON SEQUENCES TO manager;
-- 6. Reinit "public" schema
DROP SCHEMA public;
CREATE SCHEMA public;
-- 7. HERE COMES THE WEIRD STUFF, the two following statements don't have any effect at all
ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE INSERT, UPDATE, DELETE ON TABLES FROM manager;
ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE USAGE ON SEQUENCES FROM manager;
This can be easily verified like that:
-- Execute as user "admin":
CREATE TABLE public.t (id serial PRIMARY KEY, dummy integer)
-- Execute as user "manager" (it should not be allowed, but it is!)
DELETE FROM public.t;
I know I could circumvent this using some trigger functions, but the point of the question is whether this is something normal and expected, some sort of bug or am I missing something?
I have been thinking about it and the most elegant solution I could come up with relies on an Event Trigger.
Of course it does not answer my question directly, meaning that I am still wondering why default privileges cannot be used like that, but at least this meets the initial requirement of set-and-forget that default privileges would have provided.
Create a function that revokes unwanted privileges and returns an event_trigger:
CREATE FUNCTION reset_privileges() RETURNS event_trigger AS $$
BEGIN
IF EXISTS (SELECT true FROM pg_event_trigger_ddl_commands() WHERE schema_name = 'public') THEN
REVOKE INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public FROM manager;
REVOKE USAGE ON ALL SEQUENCES IN SCHEMA public FROM manager;
END IF;
END;
$$ LANGUAGE plpgsql;
Create an actual EVENT TRIGGER (This requires superuser privileges!):
CREATE EVENT TRIGGER reset_public_schema_privileges
ON ddl_command_end WHEN TAG IN (
'CREATE TABLE',
'CREATE TABLE AS',
'CREATE VIEW',
'CREATE MATERIALIZED VIEW',
'CREATE FUNCTION'
) EXECUTE PROCEDURE reset_privileges();
The function checks whether the newly created object(s) are in the public schema and eventually revokes all the unwanted privileges from the user manager.
It does not even bother to filter those objects, but rather it revokes the privileges for ALL TABLEs, VIEWs and FUNCTIONs in the public schema. Of course it can be easily customised using the object_identity field provided by pg_event_trigger_ddl_commands and a more refined logic inside the function.
According to the manual for ALTER DEFAULT PRIVILEGES:
Default privileges that are specified per-schema are added to whatever the global default privileges are for the particular object type. This means you cannot revoke privileges per-schema if they are granted globally (either by default, or according to a previous ALTER DEFAULT PRIVILEGES command that did not specify a schema). Per-schema REVOKE is only useful to reverse the effects of a previous per-schema GRANT.
(This is even more explicit in the examples given on that manual page.)
So I think what is happening is that in step 5 of your script, you are setting the default privilege to grant DELETE on the tables of all schemas (as a global default):
ALTER DEFAULT PRIVILEGES GRANT INSERT, UPDATE, DELETE ON TABLES TO manager;
But in step 7 you are revoking from the public schema specifically. This revocation has no effect on the global grant, so the DELETE (and other) privileges will still be granted:
ALTER DEFAULT PRIVILEGES IN SCHEMA public REVOKE INSERT, UPDATE, DELETE ON TABLES FROM manager;
I think I would either (a) bite the bullet and add default privileges for each schema (which isn't "fire-and-forget" but is more explicit) or (b) challenge why I need the public schema to exist, aiming to remove it to simplify this situation.
I am facing an issue while creating a readonly users in RDS PostgreSQL 9.6. I am executing the following SQL commands:
---- ###### CREATE ROLE ################
CREATE ROLE readonlyrole_dev;
-- Grant access to existing tables
GRANT USAGE ON SCHEMA public TO readonlyrole_dev;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonlyrole_dev;
-- set the privileges that will be applied to objects created in the future.
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonlyrole_dev;
CREATE USER readonly_dev WITH PASSWORD 'welcome1';
GRANT readonlyrole_dev TO readonly_dev;
When I login with the readonly_dev user, it has privilege to create the new tables by default but I don't want to do that. I want to keep readonly_dev only a read only user.
Note: To revoke the access from the user I am executing
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
which revokes create objects privilege to all old users as well. I only want to revoke create privilege from newly created user.
How can I do that?
You cannot do that, and it is not necessary either.
Just deny the user the CREATE permission on all schemas. You should use user groups for that - put all users who should have the privilege to create tables in a group that has the required privilege on the schema and revoke CREATE from PUBLIC.
If you insist that you must have this, try creating an event trigger that throws an exception whenever a certain user tries to create a table.
I have a database with a template_schema.I cloned this template schema and created a database user with password. I need to provide access to cloned schema only, for the created user.
SELECT clone_schema('my_template_schema','john_smith_gmail_com');
CREATE USER john_smith_gmail_com WITH PASSWORD 'mypassword';
Upto this Ok. Then I need to grant access to this user for this cloned schema(john_smith_gmail_com) only
Method :1
I tried to revoke all privileges on all tables of cloned schema(john_smith_gmail_com) for the user and grant select to the user. But my question is, can this user get SELECT access on other schema tables?
REVOKE ALL ON ALL TABLES IN SCHEMA john_smith_gmail_com FROM john_smith_gmail_com;
GRANT SELECT ON ALL TABLES IN SCHEMA john_smith_gmail_com TO john_smith_gmail_com;
Method :2
Create a role with only SELECT access and assign or grant this role to newly created user. If I do this, for which schema I grant access,because I clone schema dynamically?
Which method is best one?
From postgresql version 9.0 and forward, the best way is probably to use ALTER DEFAULT PRIVILEGES.
...the default privileges for any object type normally grant all grantable permissions to the object owner, and may grant some privileges to PUBLIC as well. However, this behavior can be changed by altering the global default privileges with ALTER DEFAULT PRIVILEGES.
So if all users like "john_smith_gmail_com" should only have SELECT access to tables in "their own" schema, after creating the schema and user, you can run:
ALTER DEFAULT PRIVILEGES IN SCHEMA john_smith_gmail_com GRANT SELECT ON TABLES TO john_smith_gmail_com;
I have 3 roles: superuser, poweruser and user. I have table "data" and functions data_select and data_insert.
Now I would like to define, that only superuser can access table "data". Poweruser and user can not access table "data" directly, but only through the functions.
User can run only function data_select, poweruser can run both data_select and data_insert.
So then I can create users alice, bob, ... and inherits them privileges of user or poweuser.
Is this actually achievable? I am fighting with this for the second day and not getting anywhere.
Thank you for your time.
Yes, this is doable.
"superuser" could be an actual superuser, postgres by default.
I rename the role for plain users to usr, because user is a reserved word - don't use it as identifier.
CREATE ROLE usr;
CREATE ROLE poweruser;
GRANT usr TO poweruser; -- poweruser can do everything usr can.
CREATE ROLE bob PASSWORD <password>;
GRANT poweruser TO bob;
CREATE ROLE alice PASSWORD <password>;
GRANT usr TO alice;
REVOKE ALL ON SCHEMA x FROM public;
GRANT USAGE ON SCHEMA x TO usr;
REVOKE ALL ON TABLE x FROM public;
REVOKE ALL ON TABLE y FROM public;
CREATE FUNCTION
...
SECURITY DEFINER;
REVOKE ALL ON FUNCTION ... FROM public;
GRANT EXECUTE ON FUNCTION a TO usr;
GRANT EXECUTE ON FUNCTION b TO poweruser;
Or you could create daemon roles with no login to own the functions and hold the respective rights on the table. That would be even more secure.
If you are going this route, you will love ALTER DEFAULT PRIVILEGES (introduced with PostgreSQL 9.0). More details in this related answer.
Read the chapter Writing SECURITY DEFINER Functions Safely in the manual.