I am managing a database that has a number of schemas. I am having some difficulty with setting privileges and would like to request some help.
I have the schema called schemaA and a group_role db_writer
I use the following sql:
GRANT USAGE ON SCHEMA schemaA TO db_writer;
GRANT UPDATE, INSERT, SELECT, DELETE ON ALL TABLES IN SCHEMA schemaA TO db_writer;
However, the db_writer is unable to create views. They are returned with a permission denied error. Also, when I create views, she is then unable to select them...and I have to set the priviliges again for that view.
It was my understanding the views were treated as tables with respect to privileges...and if one is granted certain permissions to all tables in a schema this would apply to views also.
What am I missing? Any advice appreciated.
The problem is USAGE does not allow users to create objects within the database.
Try
GRANT USAGE, CREATE ON SCHEMA schemaA TO db_writer
Edit:
New objects will get default privileges, for the user to have those privileges for objects created in the future you can do it as:
ALTER DEFAULT PRIVILEGES IN SCHEMA schemaA GRANT UPDATE, INSERT, SELECT, DELETE ON TABLES TO db_writer;
ALTER DEFAULT PRIVILEGES IN SCHEMA schemaA GRANT SELECT ON TABLES TO db_reader;
Check this answer for more info
Related
I need to create 3 users with different DML, DDL, DQL on newly created clean Database in PostgreSQL.
DML should have SELECT, UPDATE, DELETE
DDL should have CREATE, DROP, ALTER, TRUNCATE, INSERT
DQL should have SELECT
all of this in standard scheme public.
Important is that user inherit right on newly created tables by DDL user.
users ref: https://www.geeksforgeeks.org/sql-ddl-dql-dml-dcl-tcl-commands/
I did some coding but I'm pretty new in PostgreSQL and it didn't work :(
The main problem was that I cannot perform GRANT or REVOKE on CREATE, DROP, ALTER, TRUNCATE :(
Can someone help please?
Maybe you have something similar already prepared?
The setup you want, can be done to some extent. However these privileges are controlled on schema level, not on database level.
Assuming you have a schema app_schema for which this should be defined, you can do the following:
First create the users:
create user ddl with password '***';
create user dml with password '***';
create user dql with password '***';
Then create the schema:
create schema app_schema;
Then allow the ddl user to create objects:
grant create,usage on schema app_schema to ddl;
Then change the default privileges on the schema, so that every table (or view, or sequence ...) created by the ddl user is accessible by the dml and dql users:
alter default privileges
for role ddl
grant select,update,delete on tables
to dml;
alter default privileges
for role ddl
grant select on tables
to dql;
This will affect all future tables created in the schema by the user ddl.
The owner of the tables automatically has the privileges to INSERT,UPDATE,DELETE or TRUNCATE the tables.
I have never tried this, but it seems possible to revoke the UPDATE and SELECT privileges:
alter default privileges
for role ddl
in schema app_schema
revoke update,select,delete on tables
from ddl;
If there are already tables in the schema, you need to grant the desired privileges for them:
grant select,insert,update,delete on all tables
in schema app_schema
to dml;
grant select on all tables
in schema app_schema
to dql;
I’m pulling data from mysql ec2 instances, to s3 buckets, then creating views in redshift. I want to create database users who can only query and see certain views created specifically for them in Redshift. I have example code below that I use to create the user, view, and grant access. The issue I have is that I also have to grant access to the underlying schema the view is created from, which means the user can see and query tables in that schema. Also the user can see other schemas in the database, even ones they can’t query. Is there a way to only grant users to specific views, and make it so they can’t see other schemas they don’t have access to?
Code:
--create schema
create schema tst_user_schema;
--create view in schema
create view tst_user_schema.inventory_report_customer as (
select * from user341.inventory_report_customer
)
with no schema binding;
--creating user
CREATE USER tstuser PASSWORD 'tstPassword';
--grant access
GRANT USAGE ON SCHEMA tst_user_schema TO tstuser;
--grant read access to all tables in schema
GRANT SELECT ON ALL TABLES IN SCHEMA tst_user_schema TO tstuser;
--grant access
GRANT USAGE ON SCHEMA user341 TO tstuser;
--grant read access to all tables in schema
GRANT SELECT ON ALL TABLES IN SCHEMA user341 TO tstuser;
--grant access
GRANT USAGE ON SCHEMA tst_user_schema TO tstuser;
--grant read access to all tables in schema
GRANT SELECT ON ALL TABLES IN SCHEMA tst_user_schema TO tstuser;
to recap:
schema user341 - contains source tables, user should not be able to select from tables in this schema. You also want to hide it form the user
tst_user_schema - contains views user is supposed to be able to select from.
Looking at your GRANT statements, you're granting user unnecessarily SELECT permission on ALL TABLES IN SCHEMA user341. For views to work you only need to GRANT USAGE on that schema.
So REVOKE those permissions, and user should not be able to select.
REVOKE SELECT ON ALL TABLES IN SCHEMA user341 FROM tstuser;
Tip: to easily test permissions, you can start a session as tstuser using SET SESSION AUTHORIZATION directive and then test which statements are allowed and which not.
SET SESSION AUTHORIZATION tstuser
Regarding schema visibility - unfortunately there's no way to hide or forbid user from seening all tables and columns in all schemas. One can only restrict access to data.
I am running PostgreSQL 9.3.2 on Linux.
I have a group role 'data_scientist' and permissions to a particular (already populated) schema like so
grant usage on schema schemaname to data_scientist;
grant select, references, trigger
on all tables in schema schemaname
to data_scientist;
This fixes the problem of data_scientist using past tables. For future tables I added
alter default privileges in schema schemaname
grant select, references on tables
to data_scientist;
Still, whenever a new table is added, other data_scientist's permissions fail on the new tables.
By default, ALTER DEFAULT PRIVILEGES only applies to the role that ran the command. Suppose we have 2 users: ramfjord and animalito. If I (ramfjord) run
ALTER DEFAULT PRIVILEGES GRANT SELECT ON TABLES TO public; CREATE TABLE ramfjord_table;
Then animalito will be able to see it. If animalito runs
CREATE TABLE animalito_table
Then ramfjord won't be able to see it, because ramfjord's default privileges don't apply. See default privileges and their owners with \ddp
Because of this, we've stopped using default privileges at my company, and started using explicit GRANT's. To remove default privs, you have to run
ALTER DEFAULT PRIVILEGES FOR ROLE <owner> REVOKE...
The owner, schema, relation type and privileges have to match those listed in \ddp for this command to do anything. Do not just delete everything from the internal table that stores default privileges... trust me.
I am trying to setup a new role for making the access rights granting easier. I was wondering if there is an easier way to give select on all tables (newly created tables should be accessible automatically) under a schema to selected users. I ran following queries for the same. But still my user is not able to access the specific table.
CREATE ROLE myrole;
GRANT SELECT ON myschema.mytable TO myrole;
GRANT usage ON schema myschema TO myrole;
CREATE USER mytest1 identified BY '***';
GRANT myrole TO mytest1;
After this, when I login with mytest1 user and trying to run select on myschema.mytable it is asking me to grant usage on schema to user. After I grant usage on schema to user directly it is failing with permission denied for that table.
Please help with the same. I am running on vertica 5.0
Update:
I find that u also have to make that role default or explicitely set that role as default for user session for making the role's effect take place.
ALTER USER mytest1 DEFAULT ROLE myrole;
But still, my another question of how to make all tables under a schema accessible to specific users remains.
As per the Vertica SQL Reference Manual.pdf (page 725) (doc version 5.0 - for page numbers)
GRANT (Schema)
...
USAGE
Allows the user access to the objects contained within the
schema. This allows the user to look up objects within the
schema. Note that the user must also be granted access to the
individual objects. See the GRANT TABLE (page 727) ... .
The the user must also be granted access to the individual objects means that you need to also GRANT table.
The two I use is GRANT SELECT and GRANT REFERENCES which allows the user to run queries and join (reference) tables in the query.
Example:
GRANT SELECT ON TABLE [schema].[Table1] TO myUser;
GRANT SELECT ON TABLE [schema].[Table2] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table1] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table2] TO myUser;
...
6.0 doc reference GRANT SCHEMA (page 808) and GRANT TABLE (page 813).
I want to create a read-only user in PostgreSQL.
The intention is to have a publicly accessible data explorer, where users can write custom SQL queries.
I do this to create the user:
CREATE USER MyReadOnlyUser WITH ENCRYPTED PASSWORD 'MY_WEAK_PASSWORD';
GRANT ALL PRIVILEGES ON DATABASE "MY_DB_NAME" to MyReadOnlyUser;
GRANT ALL ON SCHEMA public TO MyReadOnlyUser;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO MyReadOnlyUser;
The intention is to give the user SELECT access to all tables, then revoke select access on the sensitive tables, and then the user can run custom queries with that db user, without any need for me to sanitize input.
Especially, he may not:
insert, delete, truncate, drop table, drop database, create table, create function/procedure, see/execute/create/drop stored procedure / functions. etc.
Sooo - now my question:
Why does this user have access to information_schema ?
It wasn't granted access to any views, and not to the schema information_schema either...
Why does this user have access to information_schema
I think select privilege is granted to PUBLIC by default on information_schema.
You should be able to do:
revoke all on all tables in schema information_schema from public;
You probably also need to revoke the select privilege on views/tables in the pg_catalog schema. But I'm not sure what this will break if e.g. psql or other client tools cannot access that information.