I have a series of stored procedures that select data from a db. I have a role (cctc_reader) that has execute permissions granted on the procedures. One of the procedure calls another stored procedure called recControl_system_option which in turn queries Information_schema.columns.
The problem is that in this proc the query
select column_name from information_schema.columns where table_name = 'recControl_manager'
does not return any records. cctc_reader has grant permissions on:
each select proc
recControl_system_option
so in theory this should work. I have no problems when run under dbo.
If I grant db_datareader to cctc_reader the query is fine, but I don't want to grant reader permissions to all tables (hence why I used stored procs). I've tried granting Select permissions on Information_schema in the Master db as suggested in some articles, but still can't get this to work.
Any suggestions?
Objects metadata visibility is subject to the VIEW DEFINITION permission:
GRANT VIEW DEFINITION ON ... TO cctc_reader;
The VIEW DEFINITION permission lets a
user see the metadata of the securable
on which the permission is granted.
However, VIEW DEFINITION permission
does not confer access to the
securable itself. For example, a user
that is granted only VIEW DEFINITION
permission on a table can see metadata
related to the table in the
sys.objects catalog view. However,
without additional permissions such as
SELECT or CONTROL, the user cannot
read data from the table.
The right securable to grant permission to depends on your scenario. It could be the dbo or some other schema, it could be the database itself, it could be individual tables. If I was in your place, I'd code sign the recControl_system_option procedure and I'd grant VIEW ANY DEFINITION on the signature at server level, a much better and secure way that using roles and granting permission on roles. See Signing an activated procedure for an example of how to sign a procedure and grant a server level permission on the signature.
As Remus mentioned, metadata visbility affects data returned when querying system tables and views. If you have no rights on a securable (object, login, whatever) it won't be visible.
Depending on your situation, you would allow the internal call to have EXECUTE AS OWNER, or wrap Information_schema.columns in a udf that as EXECUTE AS OWNER
We use this technique where we query metadata.
Found this elsewhere, make a sproc that calls System sproc sp_columns in your database. Your sproc can execute with the same permissions as your other sprocs. Downside is that the returned set has many columns that you probably are not interested in. I daresay you could refine the sproc. I chose to do the field choice in code.
CREATE PROCEDURE [dbo].[proc_tblMyTableSchemaGet]
AS
BEGIN
SET NOCOUNT ON;
exec sp_columns #table_name = 'myTable', #table_owner = 'dbo';
END
Related
I want to grant exec permission to a user. This code returns no errors but then when I see the user properties I don't see the permission granted.
GRANT EXECUTE TO #USERNAME
The GRANT statement needs both an object and a principal. You only have a principal.
What do you want to allow the user to do - execute a single Stored Procedure or all stored procedures? The object would define that. For example if your stored procedure was named MySchema.MyProc then you would apply the permissions like:
GRANT EXECUTE ON MySchema.MyProc TO MyUser
To allow the user to execute any stored procedure in the MySchema schema then it becomes:
GRANT EXECUTE ON SCHEMA::MySchema TO MyUser
While testing your scenario, I also don't see the the permission reflected in the SSMS at the user level. However, here are three ways in which I can see the permission (I called my user foo because I pity the foo):
Impersonating the user and looking at database permissions:
execute as user = 'foo';
select *
from sys.fn_my_permissions(null, 'database');
go
revert
go
Interrogating the permissions table directly:
select *
from sys.database_permissions
where grantee_principal_id = user_id('foo');
Note - the way in which you're granting permissions grants it to anything (both now and the future) which can have that permission applied. That is, all stored procedures, functions, etc in the database. If that's not what you meant to do (i.e. you only meant to grant permission to one stored procedure), then you need to specify it in the GRANT statement. I only mention this because what you're doing technically works but in my experience is more the exception than the rule.
you need to grant permissions in the database where stored procedure were created, in sql server this option is located in db login --> right click --> new
I want to create three SQL Server database roles.
That can CREATE, ALTER and EXECUTE all stored procedures in database
That can only EXECUTE all stored procedures in database
That have no access to any stored procedures in database
I have created the roles, but I'm facing issues while REVOKE their permissions.
I have executed
REVOKE CREATE PROCEDURE TO [ROLE NAME]
to revoke the permissions to create the procedure and it executed successfully.
But I got error while executing this statement:
Error: Incorrect syntax near 'ALTER'.
I am very new to SQL server role rights so I might be completely wrong with my approach.
Please guide me to achieve my goal in correct way.
Thanks
From the documentation Create a Stored Procedure:
Permissions
Requires CREATE PROCEDURE permission in the database and ALTER
permission on the schema in which the procedure is being created.
Therefore just giving CREATE PROCEDURE on it's own won't allow you to create a procedure. In fact, giving a ROLE the CREATE PROCEDURE permission, and not ALTER on the schema will result in the below error:
The specified schema name "dbo" either does not exist or you do not have permission to use it.
There is no ALTER PROCEDURE permissions, therefore, for a member of a ROLE to be able to both CREATE and ALTER a PROCEDURE you would need to do:
GRANT CREATE PROCEDURE TO YourRole;
GRANT ALTER ON SCHEMA::dbo TO YourRole; --Replace with appropriate schema name
This, however, will also enable to user to ALTER anyprocedures on said schema. Ut also enable those in the role to ALTER other objects on the schema as well (such as tables) though.
If your ROLE has permissions to ALTER the procedures and you want to remove that, you would need to run the below:
REVOKE ALTER ON SCHEMA::dbo TO YourRole;
This will, as mentioned, also revoke their ability to ALTER any other objects on said schema.
Remember, REVOKE doesn't DENY, it simply means that the USER won't inherited that permission from that ROLE any more. If the USER has the permission from a different ROLE, or they have the permission themselves, they will be able to continue to use the permission. If you must stop a USER from performing an action, regardless of any other permissions, they must have the DENY permission.
1) That can CREATE, ALTER and EXECUTE all stored procedures in
database
That's the db_owner role, or the CONTROL permission on the database. Anyone with all those permissions can escalate their own privileges to a database-level admin. So don't try.
2) That can only EXECUTE all stored procedures in database
GRANT EXECUTE TO [SomeRole]
3) That have no access to any stored procedures in database
A user has no access to any stored procedure unless you grant permissisions or add them to a role that has permissions.
I am working on the application which works on Oracle. For some kind of logic I need to get the list of tables from the given db user with the specified schema. In my case, I have a user which have granted access of the given schema. So when my code creates connection using the given credential and tries to fetch the tables from the following query, its return table list.
SELECT * FROM dba_objects where owner ='schema' and object_type = 'TABLE'
The above query was working with user having grant all privileges
but when I did try with limited permission, it is throwing error msg.
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
For the secondary user, from which our code is creating connection has granted permissions by following query
create user johnsmith identified by Passw0rd;;
grant connect to johnsmith ;
grant select any table to johnsmith ;
grant UPDATE any table to johnsmith ;
grant DELETE any table to johnsmith ;
grant INSERT any table to johnsmith ;
Which permission should I grant to user to have access on the following system tables...?
dba_objects
user_constraints
user_cons_columns
USER_TABLES
all_tab_cols
and also allow to access dbms_metadata.get_dependent_ddl() method
With the O7_DICTIONARY_ACCESSIBILITY initialisation parameter set to false, which is the default, then:
System privileges that provide access to objects in other schemas do not give other users access to objects in the SYS schema. For example, the SELECT ANY TABLE privilege allows users to access views and tables in other schemas, but does not enable them to select dictionary objects (base tables of dynamic performance views, regular views, packages, and synonyms). You can, however, grant these users explicit object privileges to access objects in the SYS schema.
So you can either grant select privileges on the specific views you need:
grant select on sys.dba_objects to johnsmith;
and the same for other views; or if you need them to have wider access to the SYS schema objects you can give them that with a role:
grant select_catalog_role to johnsmith;
though the principle of least privilege should always apply, so this may be overkill and potentially expose things you don't want that user to be able to see.
You don't need to grant anything for the user to be able to query user_* views. If you meant the DBA equivalents of those - e.g. dba_tables - then grant them as for dba_objects above; or they woudl be included in select_catalog_role. But again, only grant what is actually needed.
Either way, for dbms_metadata you can just grant privileges on that package too (you can't grant privileges on individual procedures in a package):
grant execute on dbms_metadata to johnsmith;
or - again probably much more than actually needed, and potentially much more dangerous that the select role:
grant execute_catalog_role to johnsmith
I have created some stored procedures and I am trying to execute them within a web application. To endure the security I have created SQL Server users, logins roles and permissions.
Then I grant the execute permission to the rule and give that rule to a specific user. My problem is for example if I grant execution on StoredProcedureA to roleA and the StoredProcedureA uses a select on a tableA I got the error
SELECT permission was denied on the object '[tableA]'
The error is easy to fix: I have to grant select on that table.
But since I am using many procedure in my project, it's hard to make the modification for each one. Is there a way to configure SSMS so that If I grant the execute on a procedure to a role, that role will have automatically all the permission on the actions (select, insert, update, delete) that are in that procedure?
Thanks
Can you alter your procedure to include the EXECUTE AS clause?
Example:
ALTER PROCEDURE sprocName...
EXECUTE AS dbo -- high level example
...
This would allow you to only grant your users and roles the ability to execute the procedures but the procedures the ability to do what it needs to, be that select, insert, update, etc.
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: