If user defined functions are never executed outside the context of a stored procedure, what are the reasons one might grant permissions on SQL Server user defined functions?
Should we add grant permissions when developing database creation scripts that involve creating UDFs?
A user defined function can be used outside the context of stored procedures. It is good practice to allow this granularity in database object security.
I prefer to have permissions involving roles (data reader, data writer, reports, etc.) then yes use grant permission using the creation scripts.
Take a look at this http://technet.microsoft.com/en-us/library/dd283095(v=sql.100).aspx
Related
In UNIX (and, if my memory is not betraying me, in Linux too), there is a mechanism through which execute permission is given to users (that cannot access other files) but the program itself runs with different credentials, such that the same files the invoking users cannot access, the user of the program can.
Is there any similar (or equivalent) mechanism that would allow a DB-defined user only to execute a specific procedure and nothing else, while the same procedure would have permission to invoke any other procedure within the schema and, if needed, also access other DBs?
If you grant permissions to user to execute specific procedures then user will only be able to execute those procedures. Inside those procedures you can use same schema objects or call other procedures within same schema (called "ownership chaining") or other schema if that other schema is owned by same owner.
If needed, you can use "Execute As" for stored procedures so that user rights inside procedure are different from user that calls those procedures. That gets tricky in some more complex scenarios (e.g. dynamic SQL).
It gets more complicated if you want to call procedures from other database. In that case would recommend using certificates and procedure signing (Erland Sommarskog blog is execelent).
I have an Oracle DB and I am using the system username. Using C# I created a few tables using the system username/password. When I log into sql developer and view the privileges on that table, it does not show the system user (which has a dba role and a MGMT_USER role) as having select/insert/update/delete permissions (or any permissions for that matter).
"You may not GRANT/REVOKE privileges to/from yourself"
Why does my admin user not have access to these tables and how do I get it?
What #TenG said - you can't grant privs on objects you own to yourself - you have those privs inherently as the OWNER.
More importantly, DO NOT use the SYSTEM account to create objects, especially don't create them IN the SYSTEM schema.
Use SYSTEM to create your application user, log in as THAT user, and THEN create your objects.
In Oracle, being the owner of the means you have implicit grants on the tables.
No need to grant privs to yourself on your own objects.
I have a procedure which selects data from a table in another database and also uses sp_send_dbmail. It seems execute permission is denied on cross database calls inside the procedure.
Can someone confirm that I need separate permissions on these cross database objects too or is there any way to grant execute permission so it can access anything under that proc?
This is the SQL statement for granting execute permission:
GRANT EXECUTE ON OBJECT::uspAppStoredProcedure TO AppRole;
This is the error I got:
The EXECUTE permission was denied on the object 'sp_send_dbmail',
database 'msdb', schema 'dbo'.
I got a similar error for trying to select data from another database.
This behavior is controlled by the cross db ownership chaining option in SQL Server, which is disabled by default.
uspAppStoredProcedure is attempting to execute a stored procedure outside of its ownership chain, so it would need explicit permission granted to execute the sp_send_dbmail.
It would be possible to enable ownership chaining on the databases involved, which would remove the need for granting specific permissions, but doing so would present a security risk... so it would likely be better to grant explicit access as needed.
This article goes into additional details on cross database ownership chaining.
Another potential solution would be to make use of the EXECUTE AS clause when defining the stored procedure, which would allow you to execute under the context of a different user as described in this article.
This would allow you to create a stored procedure that would allow specific users to execute it while avoiding having to grant permissions to the underlying objects directly to the users.
I've got 2 databases, let's call them Database1 and Database2, a user with very limited permissions, let's call it User1, and a stored procedure in Database1, let's call it Proc1.
I grant EXECUTE permission to User1 on Proc1; GRANT EXECUTE ON [dbo].[Proc1] TO [User1] and things worked fine as long as all the referenced tables (for SELECT, UPDATE ... etc.) are in Database1, although User1 does not have explicit permission on those tables.
I modified Proc1 to SELECT from a table, let's call it Table1, in Database2. Now when I execute Proc1 I get the following error: The SELECT permission was denied on the object 'Table1', database 'Database2', schema 'dbo'
My understanding is that SQL Server will take care of the required permissions when I grant EXECUTE to a stored procedure; does that work differently when the table (or object) is in another database?
Notes:
User1 is a user in both databases with same limited permissions
I'm using SQL Server 2005
There seem to be a difference when SQL Server checks the permissions along the permission chain. Specifically:
SQL Server can be configured to allow ownership chaining between specific databases or across all databases inside a single instance of SQL Server. Cross-database ownership chaining is disabled by default, and should not be enabled unless it is specifically required.
(Source: http://msdn.microsoft.com/en-us/library/ms188676.aspx)
Late to the party, but I recommend taking a look at signed stored procedures for this scenario. They are much more secure than granting users permissions to multiple databases or turning on database ownership chaining.
... To make it possible for a user to run this procedure without
SELECT permission on testtbl, you need to take these four steps:
1.Create a certificate.
2.Create a user associated with that certificate.
3.Grant that user SELECT rights on testtbl.
4.Sign the procedure with the certificate, each time you have changed the procedure.
When the procedure is invoked, the rights of the certificate user are
added to the rights of the actual user. ...
(From http://www.sommarskog.se/grantperm.html#Certificates)
Further documentation is also available on MSDN.
Be sure that the user is actually the same in both databases. Not just NAMED the same. Try deleting the user from both databases, then create the user under the SERVER users, and assign the appropriate permissions on each database from that single user account.
To expand on #Szymon's answer with updated text from Microsoft at the end of 2018:
Ownership chaining across databases is turned off by default. Microsoft recommends that you disable cross-database ownership chaining because it exposes you to the following security risks:
Database owners and members of the db_ddladmin or the db_owners database roles can create objects that are owned by other users. These objects can potentially target objects in other databases. This means that if you enable cross-database ownership chaining, you must fully trust these users with data in all databases.
Users with CREATE DATABASE permission can create new databases and attach existing databases. If cross-database ownership chaining is enabled, these users can access objects in other databases that they might not have privileges in from the newly created or attached databases that they create.
There is also mention about dynamic SQL and certificate signing for procedures like #Rozwel mentions in their answer.
(Source: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/enabling-cross-database-access-in-sql-server)
I want to give access to certain data, in various databases on a single sql instance, to our parent company. They don't want a web service but instead want a stored procedure, which would compile data from different data sources and return a record set.
There is a trust between our two domains so essentially they are on our domain and I will just give the required permissions to sql objects (stored procedures)
I plan to create an 'integration' database which would have the required stored procedures.
While the integration database will have no tables itself, at least for now, I do want to lock the database down so that there are no holes such as the parent company being able to create tables on database or affect permissions etc.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicity give permissions to.
As a sql DBA I make a good .net programmer ie from what I understand it will require the user of commands such as GRANT EXECUTE ON [procedure] TO [user] to grant permissions on selected stored procedures, but beyond this I am not sure of a clear strategy to achieve what I need.
I want to make sure I don't leave holes in the security.
If anyone can advise the steps I need to take, ie what commands I need to run to achieve what I want, or point me to a good article I would appreciate it.
I have already run the command REVOKE CONNECT FROM GUEST on the database.
What is the recommended approach to lock my 'integration' database down such that the parent company only has access to run the stored procedures I explicitly give permissions to.
Create a role specifically for the users from the parent company
Only grant EXECUTE to the role for the specific store procedure(s)
Grant the role the db_datareader role -- that will make sure they can't create tables, etc.