I'm pretty sure the answer is that once I grant write/alter access it explicitly gives the person access to delete.
Pretty straight forward to do this AND to test it which you really should do before you post a question.
GRANT INSERT TO YourUser
GRANT SELECT TO YourUser
GRANT UPDATE TO YourUser
DENY DELETE TO YourUser
For data; Insert, Update & Delete are all separate permissions. Granting db_datawriter is a role that grants all three, but you can grant them individually if you choose.
Select is also a distinct permission. You can technically grant someone the ability to only insert data, without the ability to select/update/delete.
For objects; Create, Alter, Drop are the separate permissions.
Related
I have given grant all privileges to role svn_dev, but it is not giving access to create, alter and drop stage permissions across all schemas. How do I provide this to a role?
I have also tried
grant ownership on database DA_DEV to role svn_dev;
I get an error
SQL execution error: Dependent grant of privilege 'CREATE SCHEMA' on securable.
To revoke all dependent grants while transferring object ownership, use convenience command 'GRANT OWNERSHIP ON <target_objects> TO <target_role> REVOKE CURRENT GRANTS'.
How to give create stage permissions?
The error message gives a way to fix it in most cases. Try this:
grant ownership on database DA_DEV to role svn_dev revoke current grants;
If you can't revoke current grants because it would be too much work to re-issue the grants, you can explicitly revoke the grants that are preventing a change in ownership. You can check them using show grants.
You can grant create stage like this:
grant create stage on schema <DATABASE>.<SCHEMA> to role <ROLE>;
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.
Fundamentally I want
my "DBA" user; the original account which has the SYSADMIN and ACCOUNTADMIN roles, to be able to see any object in the database as well as its data. It seems that at least at the level of ACCOUNTADMIN I should be able to do this.
a "power" user; via a role (dr_uce_role) I can assign at a database level where the user can do virtually everything within a database.
I thought I had made the power user role with the following code:
--grant power to engineer
grant all privileges on database dr_ev to dr_uce_role;
grant all privileges on all schemas in database dr_ev to dr_uce_role;
grant all privileges on all tables in schema dr_ev.public to dr_uce_role;
grant all privileges on all views in schema dr_ev.public to dr_uce_role;
grant select on future tables in schema dr_ev.public to dr_uce_role;
grant select on future views in schema dr_ev.public to dr_uce_role;
grant all privileges on all tables in schema dr_ev.stg to dr_uce_role;
grant all privileges on all views in schema dr_ev.stg to dr_uce_role;
grant select on future tables in schema dr_ev.stg to dr_uce_role;
grant select on future views in schema dr_ev.stg to dr_uce_role;
This user then created objects in the schemas. However my "DBA" user at SYSADMIN could not see the objects at all. With role ACCOUNTADMIN the user can see the objects, but not query them. My understanding is that ACCOUNTADMIN is the top level account, and can take ownership of these objects anyway, so if this is supposed to be a security feature I don't really understand how it is providing much protection as it can always steal ownership?
I tried changing ownership of an object as ACCOUNTADMIN to SYSADMIN, to find it had a blocking privilege;
grant ownership on dr_ev.stg.load_opportunity to sysadmin;
SQL execution error: Dependent grant of privilege 'DELETE' on securable 'DR_EV.STG.LOAD_OPPORTUNITY' to role 'DR_UCE_ROLE' 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 TO REVOKE CURRENT GRANTS'.`
I tried taking ownership with
grant ownership on all tables in schema dr_ev.stg to sysadmin revoke current grants;
which did work - although it left my power user unable to see the objects. So I granted them back with
grant all privileges on all tables in schema dr_ev.stg to dr_uce_role;
However I want my power user to be able to create or replace this table. I believe this requires the DROP TABLE privilege, although apparently my power user grants do not provide it, and I am unclear on how I should be providing it?
I will not say I have the greatest understanding of Snowflake privileges and am wondering if the statements above like grant all privileges on all tables in schema do not live at the schema level to blanket apply to all tables, but actually sets object level permissions and my original approach has simply been too granular as I do not actually wish to manage anything at object level. That being said, I am unclear in the doc how to manage at a higher level than object anyway if the statement is actually just a shortcut to set many object privileges. How can I accomplish my original goals?
The best practice for a situation like this is to grant all of your custom roles to the SYSADMIN role. This allows the sysadmin to do everything a SYSADMIN can do plus everything that all of the other roles can do. You have a lot of questions in your post, but I think this resolves many of them.
The way I did was to create a super role 'superole' and granted sysadmin, securityadmin and accountadmin to that role. I then attached the superrole to whoever I wanted to be my DBA...
How to grant select/update/insert/execute permission to all tables/procedures in database? Create role?
Because I want to have guests(all select permissions to some tables), users(only select,update,insert permissions to tables) and administrators(all permissions to all objects in database)
Approach 1) Useful when there are large no. of users.
GRANT SELECT, INSERT, DELETE, UPDATE on SCHEMA::SchemaName to Principal --often DBO for Schema
For the Principal, it is FAR preferrable to use a role and not a single user, Unless you just have a few users, it usually simplifies your management.
Now, if a utility schema is added, the user has no access to the data, but, if a table is added to the SchemaName schema, they automatically have access.
Approach 2) useful in case of few users.
adding the user to db_datareader and db_datawriter roles if you need access to all tables in the database. Its short & simple.
USE [DBName]
GO
EXEC sp_addrolemember N'db_datawriter', N'UserName'
GO
EXEC sp_addrolemember N'db_datareader', N'UserName'
Reference : http://social.msdn.microsoft.com/Forums/en/transactsql/thread/1489337c-56c9-4bb8-9875-3a75be7596be
I would create roles. Or specifically one role because there's already roles for what you describe as "guests" (i.e. the public role) and administrators (i.e. db_owner role). But let's make it real.
create role [Users];
grant select on tbl_1, tbl2, tbl3 to [public];
grant select, insert, update, delete to [Users];
exec sp_addrolemember #membername = 'yourdomain\Users', #rolename='Users'
exec sp_addrolemember #membername = 'yourdomain\Admins', #rolename='db_owner'
--no need to add people to public; everyone's a member by default
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.