I have a database (SQL Server) that is being used by 20 users, all members of the same security role. The role enables them to insert, delete and update to Table1, but they have no permissions for Table2.
Table1 has a trigger that fires a stored procedure, Table2_Refresh, that truncates Table2 and rebuilds it from Table1.
I have read in some places that the trigger and stored procedure automatically execute as the caller, and therefore uses the caller's permissions. However 19 of the 20 users are able to update Table1 and the trigger and SP execute fine. One user gets an error telling him that Table2 cannot be found.
I know I can put an 'EXECUTE AS' line in the SQL, but this is happening in multiple places, and it seems like it is an issue with the user, so I would like to solve it there if possible. Since the role memberships and permissions are identical, are there any other reasons why two users would be experiencing different behaviour from the database?
The role and permissions are clearly not identical...
Are they logging in the same way (e.g. are they all using Integrated Security)?
I suggest to check the default schema of the database user used by that special login.
If the table schema is dba but the default schema of the database user is dbo, querying the table without specifying the schema will fail.
Related
It is possible to view and analyze queries in SQL Server before implement on database and log or drop it if necessary?
For example some application send an update query to SQL Server, can I first log it to a database, and then possibly reject it if the query is illegal based on my roles?
You can use SQL Profiler to monitor queries sent to server, but you can't do what you wnat to.
If you say it is illegal for smoe roles to execute some queries it should be specified in permissions - every role have assigned permissions.
One way to achieve what you want is to define user, which mentioned applciation would use (I would even create dedicated user). Then, if you want this user to execute SELECT, just execute such command
GRANT SELECT ON [table] TO [user]
Then the user won't be able to update table, just select rows from it.
I found solution to use SQL SERVER triggers so after insert or update I check my role so if there is any access problem I can rollback transaction and send error to user.
I am struggling with schemas while creating a stored procedure in DB2 database ( 10.5 version ).
My user name is XYZ but I have to create a Stored procedure for schema ABC.
When I am trying to execute the create procedure sql I get error message which looks like Schema related
Create procedure ABC.customInsert(
IN temp INTEGER
)
BEGIN
INSERT INTO ABC.One_Column_table VALUES ( temp );
END
Error Message:
Error:DB2 SQL error:SQLCODE:-551, SQLSTATE: 42501,
SQLERRMC:XYZ;INSERT;ABC.One_Column_table
My current schema was showing XYZ earlier. ( result of select current_Schema from sysibm.sysdummy1).
I have changed it to ABC. ( using SET CURRENT SCHEMA ABC). But still the same problem.
I am able to insert, select, create UDT etc in ABC schema but the problem exists only during stored procedure creation.
Any idea what am I doing wrong ?
Based on your error message, SQLCODE -551 means that the user "XYZ" does not have the "INSERT" privilege on the table "ABC.One_Column_table".
Since you imply that you, when connected as XYZ, can insert into the table by issuing simple INSERT statements, it is possible that you possess the INSERT privilege indirectly, via a group membership. Group privileges are ignored for SQL statements in stored procedures, functions or triggers, as explained in this IBM technote.
You have two options:
Grant the required privileges on ABC.One_Column_table to the user XYZ directly.
Create a role (using the CREATE ROLE statement), grant the table privileges to that role, then grant the role to the user XYZ.
If you are curious, such behaviour is caused by the fact that static SQL statement (e.g. in a stored procedure) authorization is checked only during compilation, and the compiled code can then be executed without additional authorization checks. Groups are maintained outside the DB2 database, by the operating system, and it is possible that group membership changes after the stored procedure is compiled and without the database security administrator's knowledge. If group privileges were effective for static SQL, it would allow users who weren't originally authorized to run particular statements (i.e. were not members of the authorized group at the compilation time) still execute those statements, thus creating a security risk.
Roles, on the other hand, are maintained within the database itself by the database security administrator and thus are part of the same security landscape.
I am in the process of configuring database users for some new developers and I am running into some difficulties as I am reading lots of articles and it's not working out too well for me. I have tried various configurations manually and with T-SQL but I need a more efficient method.
My objective:
Some TSQL I can launch to give a database user the following permissions:
Grant permission to execute all Stored Procedures within the Database
Deny permission to View Definition of all of these stored procedures
Grant permission to SELECT, UPDATE, INSERT, DELETE from all tables within the database
Deny permission to View Definition of all of the tables in the database (I don't want them to view the data)
What I have tried:
I have achieved this manually but I have 200+ stored procedures and 100+ tables so I don't want to do it manually. From the T-SQL aspect I have managed to get the following to work:
USE database_name;
GRANT EXECUTE TO [security_account];
This works and allows the users to run the stored procedures but they cannot view the actual query code. I need the same logic for the tables as described above.
Thank you for your help.
I am not quite sure if this is a viable solution to your problem. But maybe it will get you at least closer to what you want. So, here is the setup I'd propose:
Do not grant anybody any permissions on any table.
Use stored procedures for DML.
Grant execute on all these stored procedures to public.
Setup one table in your database which lists all users which have access to your database including their login (suser_sname()) and their permissions (for example MayAlterTableUsers).
Implement into all stored procedures a check similar to this
if (
select isnull(MayAlterTableUsers, 0)
from tblUsers
where LoginName = suser_sname()
) > 0
begin
select N'Implementing the requested changes to tblUsers.'
end
else
begin
select N'You don''t have the required permission.'
end
Setup you views similar and grant select on all views to public
create view vShowAllUsers as
select *
from dbo.tblUsers
cross apply (
select MaySeeAllUsers
from dbo.tblUsers
where LoginName = suser_sname()
) as p
where p.MaySeeAllUsers = 1
In the end all views and all stored procedures will be publicly available but the handling of permission will be within each one of them. All permissions themselves will be within this table tblUsers. Since nobody has the possibility to alter this table tblUsers unless (of course) they are in this table with the appropriate permission, this DB setup is self-contained.
I have a scenario where I need to allow a user in one database access to objects in another database on the SAME SQL server.
SQL SERVER SETUP:
I have an SQL Server 2008 Express instance running.
Within that instance I have the following :
2 databases :
DATABASE1
DATABASE2
2 logins :
ADMIN1
ADMIN2
DATABASE1 has a user (USER1) created on ADMIN1 and has permissions on SELECT, UPDATE, DELETE, INSERT and GRANT EXECUTE on stored procedures in DATABASE1
DATABASE2 has a user (USER2) created on ADMIN2 and has permissions on SELECT, UPDATE, DELETE, INSERT and GRANT EXECUTE on stored procedures in DATABASE2
QUESTION :
What I require is to allow 'USER1' SELECT/EXECUTE permission to tables and stored procedures in DATABASE2
I have tried a few snippets of SQL from a few posts but I have no idea how to write the SQL.
I also tried doing it manually in the way of ticking checkboxes for permissions by right clicking the user and logins in Management Studio but
I need SQL to execute in my scripts.
THE REASON FOR MY QUESTION
I have tables in DATABASE1 and DATABASE2 which are related but obviously we cant create Foreign Key constraints across different databases.
The best way we have thought to handle the relationship between the 2 tables is to create a stored procedure in DATABASE1 to query the
relevant table in DATABASE2 and return a result.
Apologies for not being able to post any examples as I cannot find any examples out there through my searches which match the scenario I have described above.
If I can give any further information please let me know.
Many thanks
Kev
As long as your user is defined at the instance level, you can grant them whatever rights they need in each database. Create your users under the master, and then add them as users of each database granting them whatever rights are needed per the specific DB.
EDITED with more detail (based on comments):
First, you need to create a Database Login. This is a login that can then be added as a user to one or more databases on your instance.
Details Here (including SQL syntax): http://technet.microsoft.com/en-us/library/ms189751.aspx
Second, you need to provision the user in the database (Database1, Database2, etc...). You will want to have these users added identically to each of these product databases that gets installed. As long as the user is there, you will be able to query across the various DBs on your instance.
Details Here (Including SQL): http://technet.microsoft.com/en-us/library/aa337545.aspx
Good Luck!
I need to restrict user access to SELECT, INSERT, UPDATE and DELETE, so that user should manage data only using stored procedures I provide.
So, for instance
SELECT * FROM Table1
should return
The SELECT permission was denied on the object 'Table1'
however, if there is stored procedure SelectTable1 defined as
CREATE PROCEDURE SelectTable1
AS
BEGIN
SELECT * FROM Table1
END
(the real one contains filtering and parameters, so it is not meaningless, like the one above)
user should execute it successfully and get the resultset.
But obviously, I have no success implementing this set of permissions. Can anybody point me to some specific tutorial? MSDN was not very helpful.
Database is SQL Server 2012 and all objects (tables and stored procedures) are in custom schema.
You can do it using GRANT EXEC either on specific procedures or on schemas or on a database.
The following example grants EXECUTE permission on stored procedure
HumanResources.uspUpdateEmployeeHireInfo to an application role called
Recruiting11.
USE AdventureWorks2012;
GRANT EXECUTE ON OBJECT::HumanResources.uspUpdateEmployeeHireInfo
TO Recruiting11;
GO
Thanks to Igor I've got to the right MSDN page, and followed rights links.
However, using ownership chains suggested was too complicated for me, so I used
WITH EXECUTE AS OWNER
on my stored procedures and that works very good. When I log on using restricted user I see only procedures, no tables at all and I can execute procedures, but not even select from tables.
Also, I want to mention this concept is very similar to setuid and thus was familiar to me.
I mark Igors reply as answer, because ownership chains seem to be more generic way, just wanted to share info I found.