We would like to run a trigger on one database (A) that calls a stored procedure on another database (B).
CREATE TRIGGER trg_A ON TableA
FOR INSERT
AS
BEGIN
EXEC DatabaseB.dbo.stp_B
END
We would like to do this as LoginA with UserA on DatabaseA. We also have LoginB with UserB on DatabaseB.
How can we accomplish this?
Currently we get this error message
The server principal "..." is not able to access the
database "DatabaseB" under the current security context.
We have tried WITH EXECUTE AS 'UserB', without luck.
Interesting question. You nerd-sniped me. I tested a bunch of different scenarios.
These failed:
Trigger on tableA references stored procedure in DatabaseB. LoginA does not exist as a user in DatabaseB.
Trigger on tableA references stored procedure in DatabaseA that inserts into DatabaseB.dbo.TableB. LoginA does not exist in DatabaseB.
Created LoginA as a user on DatabaseB, but didn't give it any rights. Repeated test1 and test2. Both failed.
Created LoginB as a user on DatabaseA. Made sure LoginB could insert into DatabaseB.dbo.TableB. Logged into DatabaseA as LoginA, ran EXECUTE AS User = 'LoginB'. Tried to insert into DatabaseA.dbo.TableA.
The only way I could get the trigger to work was to create a user in DatabaseB for LoginA and grant permissions to execute the DatabaseB stored procedure.
Related
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 trying to get the information about permissions for the current user using:
SELECT HAS_PERMS_BY_NAME(DB_NAME(), 'DATABASE', 'CREATE TABLE')
SELECT HAS_PERMS_BY_NAME(DB_NAME(), 'DATABASE', 'CREATE PROCEDURE')
and this is working fine.
What is the correct syntax for CREATE TRIGGER?
I've tried :
SELECT HAS_PERMS_BY_NAME(DB_NAME(), 'DATABASE', 'CREATE TRIGGER')
and few variations with no luck. I am using SQL Server 2012.
Thanks.
The CREATE TRIGGER permission does not exist.
Check the this page to view the required permissions that lets to use CREATE TRIGGER.
To create a DML trigger requires ALTER permission on the table or view
on which the trigger is being created.
To create a DDL trigger with
server scope (ON ALL SERVER) or a logon trigger requires CONTROL
SERVER permission on the server. To create a DDL trigger with database
scope (ON DATABASE) requires ALTER ANY DATABASE DDL TRIGGER permission
in the current database.
Please can any one advise if it is possible to have a stored procedure in the [dbo] schema select data from one table in one schema for users accessing via one database role and for it to select data from a like-named table in another schema for users accessing via another database role?
For example if I have three schemas in my database:
dbo
green
red
I have two database logins [RedLogin] and [GreenLogin]. These connect to my database using respective database users [RedUser] and [GreenUser]. These users are members of the respective database roles [RedRole] and [GreenRole].
[RedUser] has a default schema of [red].
[GreenUser] has a default schema of [green].
[RedRole] has execute permission on [dbo] and select permission on
the [red] schema.
[GreenRole] has execute permission on [dbo] and select permission on
the [green] schema.
In the [green] schema I have a table called [User].
In the [red] schema I have a table called [User].
In the [dbo] schema I have a stored procedure called [User_GetAll]
that runs.
SELECT * FROM USER;
What I would like is:
For users who login with [Redlogin] and call the
[User_GetAll] get all users from the [red].[User] table.
For users who login with [Greenlogin] and call the
[User_GetAll] get all users from the [green].[User] table.
So I have a question. For example:
-[dbo] schema in the past, I had 100 stored procedures. And now, I don't want to change code in stored procedure because It's so much, so How can I do to address the problem? Please help me.
....................................................................................
Update:
For simple example:
I have a schema [dbo], and in that schema, I have created a stored procedure dbo.GetAccount:
CREATE PROCEDURE dbo.GetAccount
AS
BEGIN
SELECT * FROM tblAccountNet
END
Then, I have created a schema [ABC] with user named UserABC.
Now, I would like to login with UserABC and execute dbo.GetAccount for schema [ABC] to get all user of it and don't want to change code of dbo.GetAccount. So, how can I do?
These are my ideas to resolve it:
Create another stored procedure in [dbo] schema, and use it to read all other procedure to make them execute against schema with user when login. Can I do that? So, how can I do that?
Create a stored procedure to change schema of all [dbo] procedure to [ABC]. Can I do that?
Thanks for your help.
Your best bet here would be to use dynamic SQL. That is something which allows you to pass string variables into a script which then gets executed against the SQL engine. For example, if you had variables #dynamicsql and #usertype, you would build a dyanmic SQL string like:
#dynamicsql = 'SELECT * FROM '+#usertype+'.tblAccountNet'
Then you would execute this code in a stored procedure using EXEC(#dynamicsql). This would probably work, but it requires additional permissions for the user, and also opens you up to a whole world of security concerns, with the biggest one being SQL Injection attacks. So this would probably work, but it might be more trouble than it is worth.
http://xkcd.com/327/
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.
I'm using mssql server 2008 and having a problem with a trigger. Now, i have this aspx page, which has a stored procedure working in a button click, and that stored procedure has an execute permission for the user, lets says "x". this procedure insert some values to a table on one db. and that table has a trigger for insert, which should insert those values to some tables at other databases.
As i said, the stored procedure has an execute permission for the user "x", and the same user have insert/update/delete/select permissions on the tables that the trigger should do the insert to.
But when someone with an "x" permission starts the procedure, he/she gets this exception message : Cannot find the object "DatabaseName..table_name" because it does not exist or you do not have permissions.
But i know that database and table name is correct.
So i am thinking, maybe it has something to do with the table having permissions but i am not sure of course.
Any help with be appreciated, thanks.
Maybe you have same tables with different schemas? Your message doesn't indicate schema used.
Or your user has not other database access right? It is actually possible that user has rights to table, but his access to database itself is disabled.