I've created what I think is a very standard user with access to a single role that can query a single table:
create user new_user;
alter user new_user set password = 'some_pw';
create role new_role;
alter user new_user set default_warehouse = 'compute_wh';
alter user new_user set default_role = 'new_role';
grant role new_role to user new_user;
grant usage on warehouse compute_wh to role new_role;
grant usage on schema my_schema to new_role;
grant usage on database my_db to role new_role;
grant select on my_db.my_schema.my_table to role new_role;
GRANT OPERATE ON WAREHOUSE COMPUTE_WH TO ROLE new_role;
However, when I set this user up in a SQL client (like DBeaver), I can't run any queries:
USE WAREHOUSE COMPUTE_WH; -- fails even here
USE DATABASE my_db;
SELECT * FROM my_db.my_schema.my_table;
SQL Error [2043] [02000]: SQL compilation error: Object does not
exist, or operation cannot be performed.
What extra permissions could I be missing?
USE WAREHOUSE COMPUTE_WH; -- fails even here
If user has access to warehouse but cannot use it, it may indicate it is suspended. I would add operate privilige:
GRANT OPERATE ON WAREHOUSE COMPUTE_WH TO ROLE NEW_ROLE;
and check if auto-resume is on or explicitly start warehouse:
ALTER WAREHOUSE IF EXISTS COMPUTE_WH RESUME IF SUSPENDED;
USE WAREHOUSE COMPUTE_WH;
EDIT:
To check current role the following code could be used:
SELECT CURRENT_ROLE();
If the role is different than anticiapted, it could be changed with:
USE ROLE COMPUTE_WH;
Related
I have an application schema U32_C5 and another schema MIG_SRC which has some tables and then we have a ROLE RO_ROLE on which we have some grants of tables from Schema U32_C5.
The RO_ROLE is assigned to another Schema MRGO_RO which is Read Only.
Here I need to grant select on tables from MIG_SRC to MRGO_RO catch here is that the process which and from where I can include these grants is run from application schema U32_C5 in production so when I tried to to something like below it says table or view does not exists (which seems to be obvious)
execute Grant from U32_C5
grant select on MIG_SRC.MOBILE_CELLPHONE_PAIRINGS to MRGO_RO;
Another way which I think of is creating DB link on MRGO_RO for MIG_SRC Schema but it enables read/write operation as well on MIG_SRC tables which is not allowed on production.
DB Links is present on U32_C5 Schema for MIG_SRC Schema
So looking for a way to accomplish above task without creating DB Link any suggestion is welcome.
Sample Script of requirement what I want to achieve Please Remember I cannot and do not want Login to MIG_SRC and only way I am looking for is to do it by using U32_C5 and without DBA HELP
A RO ROLE Created by DBA's
Create role RO_ROLE;
/* Create application schema, table inside it and grant select on it to RO_ROLE*/
CREATE USER U32_C5 IDENTIFIED BY U32_C5 DEFAULT TABLESPACE;
GRANT ALTER SESSION TO U32_C5;
GRANT CREATE SESSION TO U32_C5;
GRANT CREATE database link TO U32_C5;
GRANT CREATE table TO U32_C5;
create table U32_C5_test_tab (id number);
grant select on U32_c5.U32_C5_Test_tab to RO_ROLE;
/* Create Read Only schema, grant RO_ROLE to it */
CREATE USER mrgo_ro IDENTIFIED BY mrgo_ro DEFAULT TABLESPACE;
GRANT ALTER SESSION TO mrgo_ro;
GRANT CREATE SESSION TO mrgo_ro;
grant ro_role to mrgo_ro;
/* Create SRC schema, table inside it */
CREATE USER MIG_SRC IDENTIFIED BY MIG_SRC DEFAULT TABLESPACE;
GRANT ALTER SESSION TO MIG_SRC;
GRANT CREATE SESSION TO MIG_SRC;
GRANT CREATE database link TO MIG_SRC;
GRANT CREATE table TO MIG_SRC;
create table mig_src_test_tab (id number);
/* login to Apllication Schema U32_C5 */
sqlplus U32_C5/U32_C5#SID
grant select on mig_src.mig_src_test_tab to mrgo_ro; -- for me it gives error here at this step table or does not exist
/* login to Read Only Schema mrgo_ro */
sqlplus mrgo_ro/mrgo_ro#SID
select * from mig_src.mig_src_test_tab;
or
select * from mig_src_test_tab;
If I understood you correctly, then WITH GRANT OPTION is what you're missing.
Once someone (A) grants privileges on their own objects to someone else (B), and that (B) has to "forward" those privileges to (C), then it is the WITH GRANT OPTION that helps.
Documentation says:
Specify WITH GRANT OPTION to enable the grantee to grant the object privileges to other users and roles.
Restriction on Granting WITH GRANT OPTION You can specify WITH GRANT OPTION only when granting to a user or to PUBLIC, not when granting to a role.
It means that you should grant privileges directly, not via role. That fact doesn't have to be a drawback because of named PL/SQL procedures, where privileges acquired via roles won't work anyway, so you might end up in direct grants anyway.
Other option - which you might consider - is related to what you said:
when I tried to to something like below it says table or view does not exists
If you created a synonym for those tables, then you wouldn't get such an error.
Database link isn't an option, as you said - by using it, you have full access (as you have to know username/password to create the DB link, and that isn't really read only access).
I have a user db_owner who is owner to my database called 'Sales'.
Now i have to create two groups(sales_ro and sales_riu) and then i will add users to this groups.
sales_ro group should inherit(from db_owner) read access on tables and execute on functions in Sales db
sales_riu group should inherit(from db_owner) insert and update access on tables and execute on functions in Sales db.
can we create such two groups in Postgres ?
You don't need to create groups to achieve this. You can just create Roles and assign them to the users you want. For example:
CREATE ROLE sales_ro;
CREATE ROLE sales_riu;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO sales_ro;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO sales_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO sales_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT EXECUTE ON FUNCTIONS TO sales_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT,INSERT,UPDATE ON TABLES TO sales_riu;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT EXECUTE ON FUNCTIONS TO sales_riu;
After that just grant role to expected users:
GRANT sales_ro TO your_user_1;
GRANT sales_riu TO your_user_2;
Please refer link 1 and link 2 to know more about ALTER DEFAULT PRIVILEGES and CREATE ROLE respectively.
Quoting below points from above links:
CREATE ROLE adds a new role to a PostgreSQL database cluster. A role
is an entity that can own database objects and have database
privileges; a role can be considered a “user”, a “group”, or both
depending on how it is used.
A role having the LOGIN attribute can be thought of as a user. Roles
without this attribute are useful for managing database privileges
In Apache Hive, I set the owner of a database to a role.
Users have been assigned this role.
The users cannot create table in this database.
Error is:
Principal (name=xx, type=USER) does not have following privileges for
operation CREATETABLE on object type database
How can I allow more that one user to have create table (as well as all other privileges) on a database ?
A mistake was made during the definition of the owner.
The command should have been:
alter database mydb set owner role myrole
Instead of
alter database mydb set owner user myrole
Is there a way I can grant truncate permission to a user without altering privileges in SQL Server?
The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable. However, you can incorporate the TRUNCATE TABLE statement within a module, such as a stored procedure, and grant appropriate permissions to the module using the EXECUTE AS clause.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT user_name();
Source
You can go through this official documentation.
Create a test Login and User id then grant it execute permission on the stored procedure Truncate_Table_Loner. This id will be used to perform the truncate.
-- Grant Execute Permission
-- Setup ID on Database with Connect permission
USE master
GO
CREATE LOGIN [test_user_id] WITH PASSWORD = 'JustConnect123';
GO
USE TestSQL
GO
CREATE USER [test_user_id] FOR LOGIN [test_user_id];
GO
-- Grant Permission
GRANT EXECUTE ON dbo.Truncate_Table_Loner TO [test_user_id];
GO
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).