Requirement:
User A can log in to SS instance, but only has access to database X. User A has no other access to any objects.
database X has a stored_proc called "sp_exec_dml" which takes a DML string and executes it. This stored proc would(should?) run as the owner X.
does database X, or the stored procedure ""sp_exec_dml" then need access to other dbs/objects.
for example
user A executes
exec x..sp_exec_dml N"update z..table set ..................."
I hope this makes sense. I come from an Oracle background so exactly how permissions are granted and who the grantees can be is confusing.
do databases or stored procedures have access granted to them
thanks
According to the MSDN : (URL : https://msdn.microsoft.com/en-US/library/ms345484.aspx )
To grant permissions on a stored procedure
In Object Explorer, connect to an instance of Database Engine and then expand that instance.
Expand Databases, expand the database in which the procedure belongs, and then expand Programmability.
Expand Stored Procedures, right-click the procedure to grant permissions on, and then click Properties.
From Stored Procedure Properties, select the Permissions page.
To grant permissions to a user, database role, or application role, click Search.
In Select Users or Roles, click Object Types to add or clear the users and roles you want.
Click Browse to display the list of users or roles. Select the users or roles to whom permissions should be granted.
In the Explicit Permissions grid, select the permissions to grant to the specified user or role. For a description of the permissions,
see Permissions (Database Engine).
Selecting Grant indicates the grantee will be given the specified
permission. Selecting Grant With indicates that the grantee will also
be able to grant the specified permission to other principals.
This link also explains few concepts :
(URL : https://dba.stackexchange.com/questions/6878/sql-server-stored-procedure-permissions )
Stored procedures take advantage of ownership chaining to provide
access to data so that users do not need to have explicit permission
to access database objects. An ownership chain exists when objects
that access each other sequentially are owned by the same user. For
example, a stored procedure can call other stored procedures, or a
stored procedure can access multiple tables. If all objects in the
chain of execution have the same owner, then SQL Server only checks
the EXECUTE permission for the caller, not the caller's permissions on
other objects. Therefore you need to grant only EXECUTE permissions on
stored procedures; you can revoke or deny all permissions on the
underlying tables.
If database X has "table" in
exec x..sp_exec_dml N"update z..table set ..................."
then the user should have access.
Related
I'm trying to retrieve the CREATE table statement for multiple tables from oracle SQL Developer so I can run it in SQL Management to create new tables.
However, when highlighting multiple tables and right clicking > Quick DLL> Save to File, my file looks like this:
GRANT INSERT ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT UPDATE ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT SELECT ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT DELETE ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT INSERT ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT SELECT ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT UPDATE ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
Why is there no CREATE table statements in here?
I'm connected as Opsweb and the only tables I can see are under the OPSR user.
You can't see the create DDL for other user's objects. SQL Developer is using dbms_metadata in the background, and from the documentation:
The object views of the Oracle metadata model implement security as follows:
Nonprivileged users can see the metadata of only their own objects.
Nonprivileged users can also retrieve public synonyms, system privileges granted to them, and object privileges granted to them or by them to others. This also includes privileges granted to PUBLIC.
If callers request objects they are not privileged to retrieve, no exception is raised; the object is simply not retrieved.
If nonprivileged users are granted some form of access to an object in someone else's schema, they will be able to retrieve the grant specification through the Metadata API, but not the object's actual metadata.
and so on. As the last bullet above says, you cen get the grants - which is what you are seeing now - but not the actual metadata.
If your user was granted the select_catalog_role you would be able to get the DDL for OPSR's objects, but you'd have to ask your DBA for that and it would probably be easier to connect as that user, or ask someone else who can to do that to perform the extract for you.
I am connecting to my SQL studio manager using Power BI (a report writing software). I only want tables appearing listed under a certain schema, and deny permission to access all others, instead of displaying all tables which it currently does.
Usually, when preventing individual users from accessing a schema, I would use the following code:
revoke select on schema::UnwantedSchema to User
grant select on schema::WantedSchema To User
However, now I want it so ALL users and Logins have these permission settings. Not just the individual user. Is there a way I can do this without having to set the permissions for every individual user?
If you wanted to set the privileges to multiple user logins, You need to create a role and assign the role to the ers to that role. The give required permission to the role created.
Following are the sample steps.
--Create a new role
EXEC sp_addrole 'yourRole'
GO
--Assiging role to the user
EXEC sp_addrolemember 'yourRole', 'yourUser';
GO
--Assigning permissions to the Role
GRANT ALTER, DELETE, EXECUTE, INSERT, REFERENCES, SELECT,
UPDATE, VIEW DEFINITION ON SCHEMA::YourSchema TO yourRole;
GO
GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO yourRole;
GO
What is the diffrence between...
execute as user = 'testuser'
AND
execute as login = 'testuser'
I am executing a cross database procedure under these logins and it works with the exececute as login but not the execute as user. It is saying the server principal "testuser" is nt able to access the database "xxx" under the securty context.
When i SELECT SYSTEM_USER after both commands I see that it is set to 'testuser'
execute as login provides impersonation to the entire server, since logins are on a server level. Since users are defined per database, execute as user impersonation applies only to a specific database, which is why you see the error when you cross databases.
The EXECUTE AS can be added to stored procs, functions, triggers, etc.
Example to Execute As:
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...
impersonate CALLER , which will enable to module to take on the permissions of 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.
Setting permission on objects like stored procedures can be accomplished with
GRANT EXECUTE ON <schema>.<procedurename> to <username>;
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).
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 not 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.
Login scope is at the server level while user scope is at the current database level
http://msdn.microsoft.com/en-us/library/ms181362.aspx
I want to set a readony permission to a database user.
This user should have permission to execute stored procedures
But this user should not have permission to update or inser or alter anything in database through these stored procedures or through any methord
can anyone help please
Simply don't grant permission on the stored procs that change data.
Otherwise, you could use triggers on the tables to check, but that's a bit silly compared to using permissions correctly
Note: ownership chaining means that permissions on tables won't be checked, even DENY, so this won't work.
Yes. Set the EXECUTE permission for that user, then they'll only be able to execute the Stored Procedures in your database.
GRANT EXECUTE ON dbo.storedprocedurename TO SQLUSERNAME;
You'll need to set the permissions on a procedure by procedure basis. Give them permission to stored procedures that select, and don't give them permission to the stored procedures that do updates or inserts.The best way is to setup roles, and add the users to the roles.
This is pretty flexible and you can use it to restrict exactly what uses can do. For example, it may actually be okay for them to update a table as long as they do it through a certain stored procedure. To do this you can deny them all permission to that table, but grant them permission to execute the stored proc.
give execute permission on the proc and make sure the user doesn't have write access to the tables used by the proc. Check if he is not member of the db_datawriter roled.
If you want to be 100% sure, add the user to the db_denydatawriter role
Does the following command effectively give the user, "MyUser," permission to execute ALL stored procedures in the database?
GRANT EXECUTE TO [MyDomain\MyUser]
SQL Server 2008 and Above:
/* CREATE A NEW ROLE */
CREATE ROLE db_executor
/* GRANT EXECUTE TO THE ROLE */
GRANT EXECUTE TO db_executor
For just a user (not a role):
USE [DBName]
GO
GRANT EXECUTE TO [user]
SQL Server 2005 introduced the ability to grant database execute permissions to a database principle, as you've described:
GRANT EXECUTE TO [MyDomain\MyUser]
That will grant permission at the database scope, which implicitly includes all stored procedures in all schemas. This means that you don't have to explicitly grant permissions per stored procedure.
You can also restrict by granting schema execute permissions if you want to be more granular:
GRANT EXECUTE ON SCHEMA ::dbo TO [MyDomain\MyUser]
In addition to the answers above, I'd like to add:
You might want to grant this to a role instead, and then assign the role to the user(s).
Suppose you have created a role myAppRights via
CREATE ROLE [myAppRights]
then you can give execute rights via
GRANT EXECUTE TO [myAppRights]
to that role.
Or, if you want to do it on schema level:
GRANT EXECUTE ON SCHEMA ::dbo TO [myAppRights]
also works (in this example, the role myAppRights will have execute rights on all elements of schema dbo afterwards).
This way, you only have to do it once and can assign/revoke all related application rights easily to/from a user if you need to change that later on - especially useful if you want to create more complex access profiles.
Note: If you grant a role to a schema, that affects also elements you will have created later - this might be beneficial or not depending on the design you intended, so keep that in mind.