I'm experiencing a strange behavior in Snowflake and couldn't find any explanation in the documentation.
use role accountadmin ;
use database some_database;
create schema test_schema;
drop schema test_schema;
Result:
SQL access control error: Insufficient privileges to operate on schema 'TEST_SCHEMA'
When I check the schemas with show schemas I find that the ownership of TEST_SCHEMA belongs to another role.
Snowflake documentation only says that the ownership of an object is set to the role which created it, and the only way to have it owned by another role is transfer of ownership.
I've tried granting usage on future schema to accountadmin, but it hasn't fixed the problem.
Any ideas?
The database probably has future grants set up on it that automatically assigns ownership of each new schema created
Related
If a table, schema or database is dropped accidentally, and a minute later undropped - will it lose all privileges that were granted on it?
I have read the Snowflake documentation, but they don't seem to mention that.
The grants will be recovered along with the table, meaning the roles that had the privilege on the table/object will be available for use
https://docs.snowflake.com/en/sql-reference/account-usage/grants_to_roles#columns
https://docs.snowflake.com/en/sql-reference/sql/undrop
As part of our development lifecycle we clone our prod databases to replace our dev databases, the next step is to apply the correct privileges to the newly cloned databases as our devs need full access to the dev environment whilst they shouldn't have write access to the prod environment.
So I have a requirement to change the owner of all objects in the dev databases to allow the devs to replace and update existing tables, views, procs etc. I have so far been unable to find how to achieve this.
After cloning the database, transfer ownership to another role using the GRANT OWNERSHIP (see also example) function using COPY CURRENT GRANTS clause, for example:
GRANT OWNERSHIP ON DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
GRANT OWNERSHIP ON ALL SCHEMAS IN DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
GRANT OWNERSHIP ON ALL TABLES IN DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
GRANT OWNERSHIP ON ALL VIEWS IN DATABASE mydb TO ROLE developer COPY CURRENT GRANTS;
To me the statement
GRANT OWNERSHIP ON ALL SCHEMAS IN DATABASE my_clone_db TO ROLE developer COPY CURRENT GRANTS;
executes but returns
Statement executed successfully. 0 objects affected.
even though the database has many schemas in it.
Only GRANT OWNERSHIP ON SCHEMA my_clone_db.schema_name TO ROLE developer COPY CURRENT GRANTS; seems to work but then I am back to the problem of having to execute multiple statements, one per schema.
#the_rusteiner
That is probably because the role you are running the GRANT as is not the owner of the schema. You can either do:
USE ROLE <owner_role>;
and try again or execute the GRANT OWNERSHIP as SECURITYADMIN role.
We have build a streaming pipeline that has the rights to create new tables in snowflake when they are created in the source system. (running under the role PROD_EL_ROLE)
Even though we have time travel enabled 'for backup', I want to prevent the PROD_EL_ROLE itself from being able to 'accidentally' DROP tables. AFAIK, this cannot be done directly as the creator of a table in snowflake is also the owner, and thus, is also allowed to drop the table
What I tried in addition, is to transfer the owner to another role higher in our RBAC hierarchy (PROD_SYSADMIN_ROLE) . This unfortunately only works by using REVOKE GRANTS, which is not what we want as with the creating of a table under PROD_EL_ROLE various privileges are auto-created by various FUTURE GRANTS. And we obviously don't want to remove them.
If I use COPY GRANTS, it does not work due to the PROD_EL_ROLE not having the MANAGE GRANTS right. Which is a grant we obviously do not want to give to PROD_EL_ROLE...
I only want to prevent table dropping by PROD_EL_ROLE
Any idea how to solve this?
To follow the DAC concept, you own the object created then you can customise grants to it, so no way to prevent dropping it unless a higher role in same RBAC hierarchy claims ownership, and grant back some or ALL privileges of the object to that role.
So, for your requirement here another separate process/user need use PROD_SYSADMIN_ROLE to claim objects ownership and grant back ALL PRIVILEGES on that object to role PROD_EL_ROLE
USE ROLE PROD_SYSADMIN_ROLE;
grant ownership on ALL TABLES in SCHEMA TESTDB.TESTSCHEMA
TO ROLE PROD_SYSADMIN_ROLE;
grant ALL PRIVILEGES on ALL TABLES in SCHEMA TESTDB.TESTSCHEMA
TO ROLE PROD_EL_ROLE;
Now the role PROD_EL_ROLE can do all DML operations but no DDL operations on it again (dropping/modifying the definition of the object).
While exploring Snowflake documentation on Audit Logging (user login history, object creation/deletion, query execution history etc), I found the below information.
But in my trail account, I didn't find any shared DB with name 'SNOWFLAKE'.
Would apreciate if someone can throw more light on this feature.
Neeraj
You need to choose the 'ACCOUNTADMIN' role in the context of your session to see that database.
You should set the ACCOUNTADMIN role in the context to access the SNOWFLAKE database.
Alternatively, As accountadmin, you can grant the privilege for viewing the data to other users as below.
Grant imported privileges on database snowflake to ; -- where is an existing/new role granted to
Changing the role in right upper corner is not sufficient. Yo uneed to change the role in the context.
After that, 'SNOWFLAKE' shared DB will be visible.
I have two Snowflake account and need to clone or copy the databases and tables on the same region.
Solutions that I am trying to replicate:
Data Sharing Intro Reference
I read that:
"Snowflake supports using grants to provide granular access control to
selected objects (schemas, tables, secure views, and secure UDFs) in
the database (i.e., you grant access privileges for one or more
specific objects within the database)."
It sounds like I could share a UDF with the database I want to share with the account, but read only features. This is confirmed:
" ...but cannot perform any of the DML tasks that are allowed in a
full account (data loading, insert, update, etc.)."
Setting up one account as a provider:
USE ROLE ACCOUNTADMIN;
CREATE MANAGED ACCOUNT reader_acct1
ADMIN_NAME = user1 , ADMIN_PASSWORD = 'Sdfed43da!44' ,
TYPE = READER;
//create share
CREATE SHARE Articlelibary_share;
GRANT USAGE ON DATABASE Snapshots TO SHARE Articlelibary_share;
GRANT USAGE ON SCHEMA Snapshots.public TO SHARE Articlelibary_share;
GRANT SELECT ON TABLE Snapshots.public.Articlelibary_TEST TO SHARE Articlelibary_share;
However the error I am getting the error in my worksheet that says:
SQL compilation error: Database 'SNAPSHOTS' does not exist or not
authorized.
What I have found is that when I am in the ACCOUNTADMIN role I can see the snapshot table, however, in the SYSADMIN I cannot see the the Snapshots table.
So, how can I fix the Database/Table permissions so that I can add it to the share?
The activities of creating a share and allowing access to other accounts has to be performed only by the ACCOUNTADMIN and that is the reason for the error that you are seeing.
From Documentation it is very clear :
https://docs.snowflake.net/manuals/user-guide/data-sharing-gs.html#getting-started-with-secure-data-sharing
To perform the tasks described in this topic, you must use the ACCOUNTADMIN role.