I am trying to grant usage on future stored procedures within a particular schema.
I am using the role SYSADMIN and the schema is owned by SYSADMIN.
The following statement works
GRANT USAGE ON ALL PROCEDURES IN SCHEMA UAT_CONTROL.PDS TO ROLE UAT_OPERATIONS;
While this one fails
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA UAT_CONTROL.PDS TO ROLE UAT_OPERATIONS;
"SQL Error [3001] [42501]: SQL access control error: Insufficient
privileges to operate on schema 'PDS'
Am I missing a trick?
Just wanted to provide the answer in case someone was looking for it in this forum. The MANAGE GRANTS privilege is required for future grants:
https://docs.snowflake.com/en/user-guide/security-access-control-configure.html#security-privileges-required-to-manage-future-grants
You also have to grant usage on your database and maybe on your schema:
GRANT USAGE ON DATABASE UAT_CONTROL TO ROLE UAT_OPERATIONS;
GRANT USAGE ON SCHEMA PDS TO ROLE UAT_OPERATIONS;
More infos here: https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html
Related
The only way I can get dbt run to work is by connecting as an accountadmin (bad). Any other role gives me "insufficient privileges on table xxx" when executing dbt models. I am using DBT cloud connecting to snowflake. I have created the following with a role that I wanted to use, but it seems that my grants do not work, to allow running my models with this new role.
my dbt cloud "dev" target profile connects as dbt_user, and creates objects in analytics.dbt_ddumas
Below is my grant script, run by an accountadmin:
There must be an easier way than this below, which is not even working :(
Dave
use role accountadmin;
CREATE ROLE dbt_role
GRANT ROLE dbt_role TO ROLE sysadmin
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE dbt_role
GRANT ALL ON database analytics TO ROLE dbt_role
grant ALL ON ALL schemas in database analytics to role dbt_role;
grant ALL ON future schemas in database analytics to role dbt_role;
grant ALL ON ALL tables in SCHEMA analytics.dbt_ddumas to role dbt_role;
grant ALL ON future tables in SCHEMA analytics.dbt_ddumas to role dbt_role;
grant ALL ON ALL views in SCHEMA analytics.dbt_ddumas to role dbt_role;
grant ALL ON future views in SCHEMA analytics.dbt_ddumas to role dbt_role;
CREATE USER dbt_user PASSWORD = 'Password123' MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE dbt_role TO USER dbt_user;
For anyone who is new to DBT with snowflake, here is what you need to do to setup a dbt role to run models, test, etc with dbt run, dbt test, etc
After much frustration, and a willingness to save others the pain I went through...
This is for a lower environment . Ex dev or test
Step 0: Login as an accountadmin, or have an accountadmin do this:
Step 1: create a warehouse . Ex. transform_wh
Step 2: create a database Ex. Analytics
Run this below, substituting the proper password for dbt_user:
NOTE: DO NOT CREATE ANY SCHEMAS AS ACCOUNTADMIN. That was my main problem, so do not make that mistake. The reply from the user who replied to this message did not know that, and his reply would work also. The dbt_loader_dev role will do this as you execute dbt_run. If you do, dbt_loader_dev will get "insufficient privileges" errors when trying to create schemas, tables, and views.
USE ROLE accountadmin;
-- this role is used to load all models in the dev (lower environments) when you do a dbt run, dbt test, etc
CREATE ROLE dbt_loader_dev;
-- custom roles should be granted to sysadmin
grant ROLE dbt_loader_dev TO ROLE sysadmin;
-- these grant are all you need to run so that dbt_loader_dev can do all that it needs to for any dbt run, dbt test, etc
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE dbt_loader_dev;
GRANT all ON database analytics TO ROLE dbt_loader_dev;
GRANT usage ON ALL SCHEMAS IN DATABASE analytics TO dbt_loader_dev;
GRANT usage ON future SCHEMAS IN DATABASE analytics TO dbt_loader_dev;
GRANT Monitor ON ALL SCHEMAS IN database analytics TO dbt_loader_dev;
GRANT Monitor ON future SCHEMAS IN database analytics TO dbt_loader_dev;
GRANT MODIFY ON ALL SCHEMAS IN DATABASE analytics TO dbt_loader_dev;
GRANT MODIFY ON future SCHEMAs IN DATABASE analytics TO dbt_loader_dev;
-- create a user and grant the role
CREATE USER dbt_user PASSWORD = 'Password123' MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE dbt_loader_dev TO USER dbt_user;
That's it! Enjoy!
Dave (edited)
I recommend following the excellent article by Claire on the dbt Discourse that covers this exact topic.
It would be helpful to know exactly what table, schema, or database you are unable to read from. You say my dbt cloud "dev" target profile connects as dbt_user, and creates objects in analytics.dbt_ddumas, but what databases and schemas is it reading from? (Where are your sources located)? Most of your grants will be oriented to reading existing data, since dbt Cloud will create your dbt_ddumas schema, and therefore own it and every other relation that it creates.
Assuming your raw data is located in a database called raw, then I would change your script to:
use role accountadmin;
CREATE ROLE dbt_role
GRANT ROLE dbt_role TO ROLE sysadmin
GRANT USAGE ON WAREHOUSE transform_wh TO ROLE dbt_role
grant usage on database raw to role dbt_role;
grant usage on future schemas in database raw to role dbt_role;
grant select on future tables in database raw to role dbt_role;
grant select on future views in database raw to role dbt_role;
grant usage on all schemas in database raw to role dbt_role;
grant select on all tables in database raw to role dbt_role;
grant select on all views in database raw to role dbt_role;
grant usage ON database analytics TO ROLE dbt_role;
grant create schema ON database analytics TO ROLE dbt_role;
CREATE USER dbt_user PASSWORD = 'Password123' MUST_CHANGE_PASSWORD = FALSE;
GRANT ROLE dbt_role TO USER dbt_user;
How do you grant read/select access on all functions and views to an arbitrary user?
I use psql --user=postgres -d mydb -f myview.sql to create several functions and views, and then I run:
GRANT ALL PRIVILEGES ON DATABASE mydb TO myuser;
Having been granted all privileges, I would expect myuser to now have access to the functions and views created by the postgres user. However, when I try and access them with myuser, I get a "permission denied for relation..." error. Why is this?
The reason is that you need additional privileges to access a view or table. Privileges on the database do not cover access to all objects in it.
It is different with functions: EXECUTE privilege is granted to public by default. But the function is executed with the privileges of the current user. You may be interested in the SECURITY DEFINER modifier for CREATE FUNCTION. But normally it is enough to grant SELECT on involved tables.
Per documentation about default privileges:
Depending on the type of object, the initial default privileges might
include granting some privileges to PUBLIC. The default is no public
access for tables, columns, schemas, and tablespaces; CONNECT
privilege and TEMP table creation privilege for databases; EXECUTE
privilege for functions; and USAGE privilege for languages.
You may be interested in this DDL command (requires Postgres 9.0 or later):
GRANT SELECT ON ALL TABLES IN SCHEMA public TO myuser;
While connected to the database in question, of course (see #marcel's comment below), and as a user with sufficient privileges. You may also be interested in the setting DEFAULT PRIVILEGES:
Grant all on a specific schema in the db to a group role in PostgreSQL
More detailed answer how to manage privileges:
How to manage DEFAULT PRIVILEGES for USERs on a DATABASE vs SCHEMA?
pgAdmin has a feature for more sophisticated bulk operations:
Or you can query the system catalogs to create DDL statements for bulk granting / revoking ...
Does the following command effectively give the user, "MyUser," permission to execute ALL stored procedures in the database?
GRANT EXECUTE TO [MyDomain\MyUser]
SQL Server 2008 and Above:
/* CREATE A NEW ROLE */
CREATE ROLE db_executor
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor
For just a user (not a role):
USE [DBName]
GO
GRANT EXECUTE TO [user]
SQL Server 2005 introduced the ability to grant database execute permissions to a database principle, as you've described:
GRANT EXECUTE TO [MyDomain\MyUser]
That will grant permission at the database scope, which implicitly includes all stored procedures in all schemas. This means that you don't have to explicitly grant permissions per stored procedure.
You can also restrict by granting schema execute permissions if you want to be more granular:
GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
In addition to the answers above, I'd like to add:
You might want to grant this to a role instead, and then assign the role to the user(s).
Suppose you have created a role myAppRights via
CREATE ROLE [myAppRights]
then you can give execute rights via
GRANT EXECUTE TO [myAppRights]
to that role.
Or, if you want to do it on schema level:
GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]
also works (in this example, the role myAppRights will have execute rights on all elements of schema dbo afterwards).
This way, you only have to do it once and can assign/revoke all related application rights easily to/from a user if you need to change that later on - especially useful if you want to create more complex access profiles.
Note: If you grant a role to a schema, that affects also elements you will have created later - this might be beneficial or not depending on the design you intended, so keep that in mind.
In SQL Server 2005, a user-defined database role can "own" a schema. You can see this in the properties window of the database role. What exactly does this mean in terms of permissions/privileges against the tables in that schema? What does owning a schema mean?
Or, to ask another way: If I want a particular user-defined database role to have select/insert/update/delete privileges against every table in a schema, what is the best/smartest way to accomplish this?
I could go into the permissions of every individual table in the schema and grant the privs to the role, but this seems dumb. How do I do it for the whole schema?
thanks
aj
"Own" means "has full access" or "can do anything."
If that is what you want, just make the group the schema owner.
Otherwise, grant schema-wide permissions to this group. You can grant select permission for the schema, and members of the group will be able to select from all tables in the schema, and so on.
See GRANT Schema Permissions for more info.
MSDN Documentation: db_owner
Making them members of the db_owner group for that a particular database will essentially do what you require - of course they have a few extra permissions - such as drop a database.
You could create a new user group/schema, of course as you pointed out you need to set appropriate permissions: SQL Server 2005 Permissions
I'm getting ORA-01031: insufficient privileges when creating a package my own schema. Shouldn't I have complete control over my schema. If this is not the case, what privileges does my schema need?
You may need to have GRANT CREATE PROCEDURE TO USERNAME.
If you are referencing tables that are not in your schema you may get this error even if you can select data from the tables. The problem is that permissions granted by roles work for sql but do not work for PL/SQL. PL/SQL requires the rights be granted to the user.
Another possible issue is that you do not have the create procedure system priviledge which is need to create procs.