I'm gIven the problem:
Write a script that creates a user-defined role named VendorMaintenance in the AP database. Give update permissions to that role on the Vendors table and Select permission on the Invoice and InvoiceLineItems table. Assign the VendorMaintenance role to dbMaster.
I've looked through my textbook and came up with this incorrect solution.
USE AP
GO
CREATE SERVER ROLE VendorMaintenance
GO
GRANT UPDATE
ON Vendors
TO VendorMaintenance
GO
GRANT SELECT
ON Invoices
TO VendorMaintenance
GO
GRANT SELECT
ON InvoiceLineItems
TO VendorMaintenance
GO
ALTER SERVER ROLE VendorMaintenance ADD MEMBER dbMaster
GO
It says that VendorMaintenance isn't a user, and its not. but I need to grant these permissions to the role and then assign users to that role. Also is there a better way to write this?
For a user-defined database role, the syntax is as below. The role will be created in the current database context.
USE AP;
GO
CREATE ROLE VendorMaintenance;
GO
CREATE SERVER ROLE creates a user-defined server role, which is used to grant server-scoped permissions rather than permissions on database-scoped objects.
Related
In snowflake, I have a table "dbtest"."schematest"."testtable" created by role Accountadmin.
Now i want to alter a column in this table using another role roletest;
I have given all access till table leve to roletest
# using accountadmin roles i have granted all the access
use role accountadmin
use warehouse testwarehouse
# granted database level permission to the role
GRANT USAGE ON DATABASE DBTEST TO ROLE ROLETEST;
# granted schema level permission to the rol
GRANT USAGE ON SCHEMA DBTEST.SCHEMATEST TO ROLE ROLETEST;
GRANT SELECT ON ALL VIEWS IN SCHEMA DBTEST.SCHEMATEST TO ROLE ROLETEST;
GRANT SELECT ON FUTURE VIEWS IN SCHEMA DBTEST.SCHEMATEST TO ROLE ROLETEST;
GRANT SELECT ON ALL TABLES IN SCHEMA DBTEST.SCHEMATEST TO ROLE ROLETEST;
GRANT SELECT ON FUTURE TABLES IN SCHEMA DBTEST.SCHEMATEST TO ROLE ROLETEST;
GRANT USAGE, CREATE FUNCTION, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, CREATE EXTERNAL TABLE, CREATE MATERIALIZED VIEW, CREATE TEMPORARY TABLE ON SCHEMA DBTEST.SCHEMATEST TO ROLE ROLETEST;
# also at table leve i have granted the permissions
GRANT INSERT, DELETE, REBUILD, REFERENCES, SELECT, TRUNCATE, UPDATE ON TABLE "DBTEST"."SCHEMATEST"."testtable" TO ROLE "ROLETEST";
Now when i try
use role roletest;
use warehouse roletest_wh;
alter table "DBTEST"."SCHEMATEST"."testtable" alter column c1 drop not null;
i get the error
SQL access control error: Insufficient privileges to operate on table 'testtable'
I also tried
GRANT OWNERSHIP ON "DBTEST"."SCHEMATEST"."testtable" TO ROLE roletest;
it gives error
SQL execution error: Dependent grant of privilege 'SELECT' on securable "DBTEST"."SCHEMATEST"."testtable" to role 'SYSADMIN' exists. It must be revoked first. More than one dependent grant may exist: use 'SHOW GRANTS' command to view them. To revoke all dependent grants while transferring object ownership, use convenience command 'GRANT OWNERSHIP ON <target_objects> TO <target_role> REVOKE CURRENT GRANTS'.
https://docs.snowflake.com/en/sql-reference/sql/grant-ownership.html#examples
In a single step, revoke all privileges on the existing tables in the mydb.public schema and transfer ownership of the tables (along with a copy of their current privileges) to the analyst role:
grant ownership on all tables in schema mydb.public to role analyst copy current grants;
Grant ownership on the mydb.public.mytable table to the analyst role along with a copy of all current outbound privileges on the table:
grant ownership on table mydb.public.mytable to role analyst copy current grants;
Only the owner of an object can alter that object.
When changing ownership you need to use one of the revoke/copy grants options
Can we hide tables from users upon creation in Snowflake?
Can we setup an access control rule using wildcards on table names? Ex: revoke access to users if table name like '%ETL_TRANSIT%'?
OR
When creating a table/view, do we have an option to choose "not visible to users"?
You will first have to be using a different role to create the tables than the role that will be viewing the tables. I would recommend reviewing the Role-based Access Controls in the documentation: Role Hierarchy and Privilege Inheritance
I'm going to use SYSADMIN as the role that creates objects, and a create a new role for viewing called VIEWER just as an example. If you have SYSADMIN access you can test this out yourself:
USE ROLE sysadmin;
CREATE OR REPLACE DATABASE demo_db; -- creating a new db just for demo purposes
CREATE OR REPLACE SCHEMA demo_schema;
USE ROLE securityadmin; -- Use the securityadmin or useradmin to create and manage roles
CREATE ROLE viewer;
GRANT ROLE viewer TO ROLE sysadmin;
-- Now go check out the Roles page in Snowsight under Admin --> Users & Roles
-- You should see viewer underneath sysadmin
USE ROLE viewer; -- You will see nothing because you don't have access to anything
USE ROLE securityadmin;
GRANT USAGE ON WAREHOUSE compute_wh TO ROLE viewer; -- viewer needs a WH to access data
GRANT USAGE ON DATABASE demo_db TO ROLE viewer;
GRANT USAGE ON SCHEMA demo_db.demo_schema TO ROLE viewer;
USE ROLE viewer; -- You will see the db and the schema now
-- Follow this for each new table you create:
USE ROLE sysadmin;
CREATE OR REPLACE TABLE demo_db.demo_schema.demo_tbl (col INT);
USE ROLE viewer; -- You will not see the new table
USE ROLE securityadmin;
GRANT SELECT ON demo_db.demo_schema.demo_tbl TO ROLE viewer;
USE ROLE viewer; -- You will now see the new table and be able to query it
Do NOT grant SELECT on FUTURE TABLES or FUTURE VIEWS in a schema though. IF you do that, the Viewer role will automatically see new tables as you create them. You will want to grant SELECT one at a time based on your requirements.
This is an answer to your second requirement. You could build out a Stored Procedure that could GRANT based on a like, but it would be a highly custom option that would need to run on a schedule or triggered manually.
Unless you have future grants in place or a role is inheriting the role used to create the table, most roles do not automatically gain access to tables created by other roles. You would need to explicitly grant them permissions on the new table (and the table's associated schema/database) in order for the table to be "visible" to the role.
I have almost 20+ Databases each db contains lot of procedure trigger view etc, also have development windows user group, i have to give view and execute privilege to the group members. Also read,write,update,delete privilege to tables. How i can give all together ?
I am using SQL 2012
At a pure guess, and assuming the AD group already has a user on the database. You'll need to replace parts in the braces ({})
USE {Your Database};
GO
--create an executor role
CREATE ROLE db_executor;
GRANT EXECUTE TO db_executor;
GO
--Add AD group to roles.
ALTER ROLE db_datareader ADD MEMBER [{Your Domain}\{The AD Group}];
ALTER ROLE db_datawriter ADD MEMBER [{Your Domain}\{The AD Group}];
ALTER ROLE db_executor ADD MEMBER [{Your Domain}\{The AD Group}];
I have been using the following SQL to create a user, login and database.
USE master;
GO
CREATE DATABASE TEST;
GO
USE TEST;
GO
CREATE LOGIN TEST_USER WITH PASSWORD = 'password';
EXEC sp_defaultdb #loginame='TEST_USER', #defdb='TEST'
CREATE USER TEST_USER FOR LOGIN TEST_USER WITH DEFAULT_SCHEMA = DBO;
EXEC sp_addrolemember 'db_owner','TEST_USER'
GO
GRANT ALL TO TEST_USER;
GRANT ALTER ON SCHEMA::dbo TO TEST_USER
GO
When asked, I found myself being unable to explain the difference between making my user the owner of the database (in order to create/alter/drop tables etc):
EXEC sp_addrolemember 'db_owner','TEST_USER'
and granting all to the user, which I thought gives essentially the same privileges.
GRANT ALL TO TEST_USER;
Are they the same? Or is it true what my Mother always said: you can lead a horse to water, but that doesn't make him a DBA?
Rob
:)
Owners of a securable cannot be denied permissions. But a user that is granted ALL can still be denied by explicit DENY on a securable (DENY takes precedence over all/any GRANT). So user that is member of the group Foo can have ALL permissions granted trough the group membership, but if he is also member of group Bar that is denied SELECT on table X then the user will be denied to select from said table. If the user would be owner of table X then the DENY would not affect him. This applies to any object, at any level, including database ownership and dbo.
This would be the difference between granting ALL and ownership, but note that membership to the fixed role db_owners is different from being dbo though. Specifically, groups do not own securables, users do (or at least that how it should be... but I digress).
In addition to the owner being immune to DENY, in SQL Server GRANT ALL is deprecated, and it doesn't grant all possible permissions. (DENY ALL and REVOKE ALL are also deprecated.)
This option is deprecated and maintained only for backward
compatibility. It does not grant all possible permissions. Granting
ALL is equivalent to granting the following permissions.
If the securable is a database, ALL means BACKUP DATABASE, BACKUP LOG,
CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE,
CREATE RULE, CREATE TABLE, and CREATE VIEW.
If the securable is a scalar function, ALL means EXECUTE and
REFERENCES.
If the securable is a table-valued function, ALL means DELETE, INSERT,
REFERENCES, SELECT, and UPDATE.
If the securable is a stored procedure, ALL means EXECUTE.
If the securable is a table, ALL means DELETE, INSERT, REFERENCES,
SELECT, and UPDATE.
If the securable is a view, ALL means DELETE, INSERT, REFERENCES,
SELECT, and UPDATE.
And you can GRANT ALL without also using WITH GRANT OPTION.
I Just need to create table from a user to any user under the same DB.
letz consider 3 Schemas.
Schema_1,Schema_2 and Schema_3.
schema 1 had DBA Privilege.
Is it possible to table in SChema_2 or Schema_3 from Schema_1????
or we need to give this role "CREATE ANY TABLE" also ??
The DBA role should have this privilege in a typical installation - you can see other roles/users who have this by:
select grantee from dba_sys_privs where privilege = 'CREATE ANY TABLE'
As #dpbradly states, Oracle "out of the box" privileges for the DBA role include the 'CREATE ANY TABLE' privilege. You can check this out with the following query (and see all the system privileges granted to this role as well):
SELECT * FROM role_sys_privs WHERE role = 'DBA' ORDER BY PRIVILEGE;
The Oracle data dictionary is your friend.
Ok lets make some things clear
CREATE ANY TABLEis system privilege not role
you can grant any user DBA privileges by simply writing GRANT DBA TO <USER_NAME> WITH ADMIN OPTION;
That being said, schema_1 will be able to create table on any user as he have CREATE ANY TABLE privilege
create table hr.dbaMade_tab
(id number,
name varchar2(20)
);
If you schema_1 grants CREATE ANY TABLE then schema_2 and schema_3 will be able to create table to any table.
Do not grant DBA role to anyone. Make new role and give it necessary privileges and grant that role to other users. In your case schema_2 and schema_3. Hope that helps.