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.
Related
UPDATED question:
The core of my problem is: The stored procedure I (User1) created is not able to select from the some specific table (table1 created by another user (User2)) due to:
CREATE OR REPLACE PROCEDURE TEST_SCHEMA.TEST_PROCEDURE(OUT r_count INTEGER)
LANGUAGE SQL
BEGIN
SET r_count = (SELECT COUNT(*) FROM TEST_SCHEMA.TABLE1);
END
OK. No rows were affected
SQLWarning: Code: 20480 SQL State: 0168Y
--- The newly defined object "TEST_SCHEMA.TEST_PROCEDURE" is marked as invalid because it references an object "TEST_SCHEMA.TABLE1" which is
not defined or is invalid, or the definer does not have privilege to
access it.. SQLCODE=20480, SQLSTATE=0168Y, DRIVER=4.22.29
However, when I select from table1 in a normal query window there is no problem, hence I thought something was wrong about the security option on the stored procedure
SELECT COUNT(*) FROM TEST_SCHEMA.TABLE1
Table and stored procedure names are fully qualified. The stored procedure is created and executed by user1. The privilege given to the user1, to select from table1 , is a group privilege.
The procedure creator must have the corresponding privilege on statically referenced table either directly or via roles.
CREATE PROCEDURE (SQL) statement:
Authorization
The privileges held by the authorization ID of the
statement must include at least one of the following authorities:
If the implicit or explicit schema name of the procedure does not exist, IMPLICIT_SCHEMA authority on the database.
If the schema name of the procedure refers to an existing schema, CREATEIN privilege on the schema.
DBADM authority
The privileges held by the authorization ID of the statement must also
include all of the privileges necessary to invoke the SQL statements
that are specified in the procedure body.
To replace an existing procedure, the authorization ID of the
statement must be the owner of the existing procedure (SQLSTATE
42501).
Group privileges are not considered for any table or view specified in
the CREATE PROCEDURE (SQL) statement.
I have a HANA database deployment set up using Flyway and the HANA JDBC driver that creates and populates a schema. Something I would also like to do as part of the deployment is grant a particular database role read access to that schema. However, in order to avoid migration errors, I'd first like to verify that this role exists, and I can't get this part of the logic to work.
The closest I've come is
DO
BEGIN
DECLARE I INTEGER;
SELECT COUNT(*) INTO I
FROM roles
WHERE role_name = 'MYROLE';
IF I > 0
THEN
GRANT SELECT ON SCHEMA myschema TO MYROLE;
END IF;
END;
but this fails with
SQL State : HY000
Error Code : 7
Message : SAP DBTech JDBC: [7] (at 140): feature not supported: DDL statements other than CREATE/DROP TABLE is/are not supported in anonymous block: line 9 col 9 (at pos 140)
Location : db/migration/V1.10__my_script.sql (snip)
Line : 1
Statement : DO
I also tried this via trying to create a temporary stored procedure and executing that - same problem with DDL statements not being supported.
The problems:
I need to do an IF-THEN-ELSE based on the result of a select query
HANA doesn't seem to support nesting a SELECT statement inside an IF clause, so I need to save the result in a variable and use that instead
Declaring variables is only supported inside blocks, such as anonymous blocks or the bodies of stored procedures
Blocks also forbid executing most DDL statements - GRANT being one of them.
At this point, I'm not sure if what I'm trying to do is even possible. Pointers would be very much appreciated.
Your code should work with a few modifications like the following:
DO
BEGIN
DECLARE I INTEGER;
SELECT COUNT(*) INTO I
FROM roles
WHERE role_name = 'MYROLE';
IF :I > 0 THEN
exec 'GRANT SELECT ON SCHEMA myschema to MYROLE';
END IF;
END;
To access the I variable value in the IF statement you need to use the : notation.
As you mentioned some DDL statements are not directly supported in SQL Script, but you can use the EXEC command to run them as dynamic SQL commands.
Generally speaking, this approach to handle privileges is rather problematic since the outcome of your procedure, that is what privileges exactly are available to MYROLE, is dependent on
if there already exists a role with the same name
what privileges the security context that runs the procedure is allowed to grant
SAP HANA provides HDI (HANA Deployment Infrastructure) repository object type .hdbrole that allows to bundle privileges into roles and have those deployed fully (or not at all) upon installation time. This approach also allows updating privilege assignments to roles even after the role had been assigned to other roles and users without the need for re-assignment.
Dynamically building roles and assigning privileges makes it much harder to understand when, where and why privileges are assigned to roles/users. That is typically not what you want; instead, you like to have privileges assigned at a well-known place in your application and nowhere else. Therefore the pointer is to actually not use your procedure but to use the HANA tools available for role-definition.
All that is explained in a lot more detail in the SAP HANA documentation.
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 am using insert statement and trying to insert data into the database table. I am using stored procedures.
But I am getting this error while doing so.
Message: ORA-00942: table or view does
not exist ORA-06512
I checked if the tables/stored procedures are present or not and everything is in place. Also there is no typo in table names or in sp. If I run the part of SP from query editor it works fine but when I execute the entire SP it throws an error.
I tried the steps provided by Stephen but since I have logged in with the same user/owner when I run Grant command it gives me an error saying 'Cannot Grant/revoke on own'.
One more addition to this. I have a stored procedure SP1 in which I am using a select statement as
Select a from table_name where condition;
When I execute this seperately, it returns me some results. But when I execute sp it gives an error at the same line where it is written.
Can anyone help me out to resolve this issue. I am using SQL +.
Thanks in advance
Vijay
Justin's answer is correct but let me expand a bit.
Everyone who said that the table doesn't exist didn't read your whole post. Since you are able to:
If I run the part of SP from query editor it works fine
Obviously the table is there.
Obviously you have some access to it. Otherwise this wouldn't work when it clearly does.
but when I execute the entire SP it throws an error.
This is because Oracle distinguishes between permissions granted directly and those granted via a role.
Say I do this:
Create Table TABLE_A
Create Role READ_ONLY
Grant Select on TABLE_A to READ_ONLY
Grant READ_ONLY to VIJAY
In a SQL Window/prompt you could query that table without issue. So now you need to create a view
Create VIJAY.VIEW_A as SELECT * FROM TABLE_A
You'll get the error that TABLE_A does exist. Because a view is compiled, like a procedure it runs without any roles. Since it runs without the READ_ONLY role, it's blind to the fact that TABLE_A exists. Now what I need to do is
Grant Select on TABLE_A to VIJAY.
Now that you have a direct permission, you can compile a view or procedure/package that uses that table.
Does the table exist in the schema where the stored procedure exists? If not, the simplest explanation is that the owner of your procedure has been granted access to the table via a role not via a direct grant. A definer's rights stored procedure needs to have direct access to the objects it accesses. A quick way to test this is to disable roles for the session, i.e.
SQL> set role none;
SQL> <<execute your query>>
If that generates the error, the problem is the lack of a direct grant.
In Oracle you can choose if the stored procedure is executed with the rights of the invoker or the definer: http://download.oracle.com/docs/cd/E11882_01/appdev.112/e17126/subprograms.htm#i18574
Check if the AUTHID property of the stored procedure is correct and if the resulting user has appropriate permissions.
Well, put very simply, the table that you are trying to insert data into does not exist in the database you are connected to. You need to check both those things (i.e. what are you connected to, and is the table there and accessible for the user context you are using).
As Joe Stefanelli said .. there are a lot of possibilities for the error being shown here.
Check whether:
You are connecting to the correct Oracle Instance.
You have permissions to query or perform processing on table that you are referencing in your query.
There is a difference between ordinary select statements and procedures. Procedures in oracle do not respect the roles assigned to a user; rather the permission needs to be explicitly granted to the user. For more information read the following linkORA-00942