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
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
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.
Can I grant select permission on all database to a user-defined role?
I create a user-defined server role, and add logins as members of it.
I want these logins can view all databases and have select permission on all databases.
how should I do?
exec sp_addrolemember db_datareader, <User-Defined Role>;
This is equivalent to granting SELECT on all tables in the DB.
I'd like to set up a security situation where my database user ("ApplicationUser") has permission to create, alter and drop views within a schema.
If I execute the statement
GRANT ALTER ON SCHEMA :: MySchema TO ApplicationUser;
And then connect to the database and execute the statement:
CREATE VIEW [MySchema].[MyView] AS SELECT * FROM SomeTable
I get the error message
CREATE VIEW permission denied in database 'MyDatabase'.
Is it possible to configure security the way I want, or must I grant "ALTER" on the whole database? Or something else?
Thanks for your help!
create schema myschema authorization ApplicationUser
GO
grant create view to ApplicationUser
GO
To do this you need to either change the authorization of the schema, which may have other consequences, or use something like a database DDL trigger.
For an existing schema do:
alter authorization on schema::myschema to ApplicationUser
Like I say, this way should be done with caution. For the other way http://msdn.microsoft.com/en-us/library/ms186406(v=sql.105).aspx
I was able to do this by...
Granting a create view/select permission on the database to a role
Grant alter permissions to that role for the schemas I want to have views
Deny alter permission to that role for the schemas I didn't want to have views
Here was my syntax...
USE [database];
CREATE ROLE [role];
GRANT SELECT TO [role];
GRANT CREATE VIEW TO [role];
GRANT ALTER ON SCHEMA::[schema 1] TO [role];
DENY ALTER ON SCHEMA::[schema 2] TO [role];
--TEST
/*
EXECUTE AS USER = '[user w/role]';
CREATE VIEW [schema 1].test AS (select 'test' as 'test');
DROP VIEW [schema 1].test
CREATE VIEW [schema 2].test AS (SELECT 'test' AS 'test');
DROP VIEW [schema 2].test
REVERT
*/
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.