I am running a schema compare between two databases to make sure their schemas are identical. On most of the tables, the only thing different is permission.
Names changed to protect innocent databases. "Otherone" is the sql login I am currently using, that has additional rights compared to most users.
Does AS [principal] part matter?
I tried to change it but got an error about rights.
I'm not new to sql but I am new to the security side of it.
For example
Database A:
GRANT INSERT ON OBJECT::[someschema].[sometable] TO [somerole]
AS DBO
Database B:
GRANT INSERT ON OBJECT::[someschema].[sometable] TO [somerole]
AS OTHERONE
AS Specifies a principal from which the principal executing this query derives its right to grant the permission.
The grantor (or the principal specified with the AS option) must have either the permission itself with GRANT OPTION, or a higher permission that implies the permission being granted.
If you are using the AS option, the following additional requirements apply:https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-object-permissions-transact-sql?view=sql-server-2017
Related
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...
I am learning oracle and PL/SQL. I have created a database called "PRACTICE" and created a user called "MITHRA" by connecting as a SYS.
My question is i want to grant privileges to the user "MITHRA" for the specific database "PRACTICE". The user "MITHRA" can able to do all activities like create, drop, alter etc.. only in "PRACTICE" database.
Please suggest me how to do this.
Oracle can only host one database so what you are asking for will essentially grant root privileges to this user, including drop database. This should be avoided on production from obvious reasons.
So in order to grant full access to user mithra:
Connect as sys and run the following command -
Grant dba to mithra;
That should give the user mithra all possible privileges for that database.
You can also use the grant command the grant any distinct privileges.
Just to be sure that we speak in the same terms.
Is the "PRACTICE" database or schema? If it is DATABASE then you should grant DBA, if it is schema then Oracle does not have statements to grant rights to schemas (only system and object priveleges). Reading your question makes me think that you come from MSSQL where you can grant to a specific user gratns to specific database, in Oracle it is a little bit different - to make an analogy - you do not have databases but schemas.
I have been granted db_datareader access to our production SQL Server database, but they also granted me the denywrite permission, as a safety precaution to make sure I absolutely cannot break our services during the course of my investigations.
However, I am finding that I cannot see our stored procedures - the list appears empty.
We should have hundreds of stored procedures in our production environment, so I'm perplexed as to why they aren't showing up in the object explorer.
Our infrastructure manager granted me the rights, but he doesn't know anything about SQL Server, so management has asked me to assist with figuring out which SQL Server permissions I need, since I am the developer.
So I need to know what I'm missing here - I assumed db_datareader would let me view everything, including stored procedures and metadata, but apparently I was mistaken. :)
Admittedly, I'm not the most knowledgeable when it comes to permissions. However, I believe the minimum permission you need here is view definition. You can also grant this permission to a role if it makes more sense for your situation.
use MyDB
GO
GRANT VIEW DEFINITION to MyUser
The above will grant view_definition to MyUser for the MyDB database.
Changing to the following will grant view definition on any database:
use master
GO
GRANT VIEW ANY DEFINITION to MyUser
Sources:
https://msdn.microsoft.com/en-us/library/ms345443.aspx#Security
http://www.mssqltips.com/sqlservertip/1593/granting-view-definition-permission-to-a-user-or-role-in-sql-server/
What Server Role(s) and/or Database Role(s) must a SQL Login have to do the following:
Read Data (including Temp tables)
Write Data (including Temp tables)
Execute any SP within a database which they are granted access
We are migrating from SQL 2000 to 2008 and I'm going through all the Logins and have noticed they are all set to sysadmin & db_owner, which isn't good. Our apps that use these logins will only do what I've listed above so that's why I'm wondering. I know I can set each Login with a Database Role of db_datareader & db_datawriter but that doesn't include executing SP's. We've got close to 300 SP's in 2 or our DB's and to have to go through each SP and set the login permissions in the Extended Properties would be WAY too long and tedious.
Any help is greatly appreciated!
to have to go through each SP and set the login permissions in the Extended Properties would be WAY too long and tedious
And yet, this would also be the most secure.
Using the built in roles exposes too much of your database to your application.
Can you give the db_datareader and/or db_datawriter execute rights? This will give the user rights to execute any stored procedures in databases it has access to. If you have views you will also need to grant them select rights.
GRANT EXECUTE TO db_datawriter
I would either just deal with it and set the permissions manually or (my preference) create database roles that have the types of permissions you want to give, and assign logins to those. That way if multiple logins need the same set of permissions, you just give them the same role.
As a bonus, if your programmability objects have some sort of prefix naming convention so that (for example) procedures that read from your login information tables all start with something like pAccount_ or something, then you can dynamically do GRANTs to roles based on the prefix of the routine.
Is there a way I can give developers permission to grant a user permissions over objects without giving them the option to create users or functions?
I'm trying to limit developers permissions, I recently found out that developers had db_owner permissions in dev and prod environments! So I'm doing my best to stop this madness.
Any good article about this matter?
You can make them members of the "db_securityadmin" database role
As said, if someone could hand out permissions, they could hand out permissions to themselves (or a dummy account). I'm not sure if there is a trick in SQL Server to provide "give user permissions less then me".
The way I would do it is with stored procedures.
Create a stored procedure that gives a specified user a specific right or set of rights (those rights are the ones that regular users are allowed to have). Then give the developers execute access to this stored procedure. In effect you use stored procedures to create a limited version of GRANT, while keeping the full GRANT command to yourself.
If someone can give someone else permissions, he can also give himself the permission to do what he wants. So what is this good for? Probably I don't understand your situation.
Owners of objects can grant permissions on those objects. Provided your developers don't need to grant things like CREATE TABLE rights, you might be able to give them ownership of the objects that you want them to grant permission on.
As Stefan said, giving them grant permissions would effectively give them all permissions, since if they want to do something all they have to do is grant themselves the permissions to do it.
Rather than considering the developers the enemy, though, you may want to consider giving the developers a second user account that's used to administer the database. It's pretty common not to give developers ANY permissions to production, at least on their development account.
Setting permission on objects like stored procedures can be accomplished with "GRANT EXECUTE ON . to ;
However, you may also want to grant security rights at both the login and user level. You will want to determine and grant ONLY the necessary rights for the objects that require access (such as execution). Consider use of the "EXECUTE AS" capability which enables impersonation of another user to validate permissions that are required to execute the code WITHOUT having to grant all of the necessary rights to all of the underlying objects (e.g. tables). The EXECUTE AS can be added to stored procs, functions, triggers, etc.
Add to the code as follows right within the Stored Procedure: CREATE PROCEDURE dbo.MyProcedure WITH EXECUTE AS OWNER
In this case you are impersonating the owner of the module being called. You can also impersonate SELF, OR the user creating or altering the module OR... imperonate CALLER , which will enable to module to take on the permissionsof the current user, OR... impersonate OWNER, which will take on the permission of the owner of the procedure being called OR... impersonate 'user_name', which will impersonate a specific user OR... impersonate 'login_name' with will impersonate a specific login.
MOST of the time, you will only need to grant EXECUTE rights to stored procs and then rights are granted to all objects referenced within the stored proc.
In this way, you DO NO need to give implicit rights (example: to update data or call additional procs). Ownership chaining handles this for you. This is especially helpful for dynamic sql or if you need to create elevated security tasks such as CREATE TABLE. EXECUTE AS is a handy tool to consider for these.
This example may help clarify all of this:
Create a user called NoPrivUser with public access to a database (e.g. dbadb)
USE [master] GO CREATE LOGIN [NoPrivUser] WITH PASSWORD=N'ABC5%', DEFAULT_DATABASE=[dbadb], CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO USE [DBAdb] GO CREATE USER [NoPrivUser] FOR LOGIN [NoPrivUser] GO
NOTE: CREATOR OR OWNER OF THIS PROCEDURE WILL REQUIRE CREATE TABLE RIGHTS within the target database.
use DBAdb go CREATE PROCEDURE dbo.MyProcedure WITH EXECUTE AS OWNER AS IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].MyTable') AND type in (N'U')) CREATE TABLE MyTable (PKid int, column1 char(10)) INSERT INTO MyTable VALUES (1,'ABCDEF')
GO
GRANT EXEC ON dbo.MyProcedure TO NoPrivUser; GO
-- Now log into your database server as NoPrivUser and run the following.
use dbadb go
EXEC dbo.MyProcedure
(1 row(s) affected)
Now try to select from the new table while logged on as NoPrivuser.
You will get the following:
select * from MyTable go
Msg 229, Level 14, State 5, Line 1 The SELECT permission was denied on the object 'MyTable', database 'DBAdb', schema 'dbo'.
That is expected since you only ran the procedure under the security context of Owner while logged on as NoPrivUser.
NoPrivUser as no rights to actually read the table. Just to execute the procedure which creates and inserts the rows.
With the EXECUTE AS clause the stored procedure is run under the context of the object owner. This code successfully creates dbo.MyTable and rows are inserted successfully. In this example, the user "NoPrivUser" has absolutey no granted rights to modify the table, or read or modify any of the data in this table.
It only takes on the rights needed to complete this specific task coded WITHIN the context of this procedure.
This method of creating stored procedures that can perform tasks that require elevated security rights without permanently assigning those rights come be very useful.
I've found that the most dangerous aspect of the db_owner role is that if you issue a deny on a permissions, then the members of the role can grant it back to themselves. I've just started reading about this and I'm testing this
Create role db_ControlDatabase
grant control to db_ControlDatabase
deny backup database to db_ControleDatabase
alter role db_ControlDatabase add member TestUser
So far, I've found that the subject TestUser has permissions without being able to add or remove members of the fixed database roles. You should be able to deny whatever you need at this point like backup certificate, backup master key, etc.
Here is a list of permissions that can be denied or granted: