I have one HDI container (HDI1) that access an Table Function (TF_1) in another HDI container (HDI2), I create the synonym, It`s OK, working fine.
But when the TF_1 calls another Table Function (TF_2) in HDI2 I get "Insufficient Privilege" error. I have to create a synonym to TF_2.
Is It Correct? Why I don`t need to do this for another object Type (E.g. Calculation Views)
Thank you
I've reproduced this scenario without HDI, but with plain SQL schemas and users instead.
Creating and running TF_1 and TF_2 as the owner of HDI 2 is working fine.
Granting EXECUTE on TF_1 to the owner of HDI 1 works also fine. HDI 1 can successfully run TF_1 afterward, but not TF_2.
So far, so good.
With HDI the situation becomes more complex as your developer user is not the owner of HDI 1 schema.
Instead, upon activation/deployment of your code, the HDI infrastructure connects as the actual owner of HDI 1 to create the objects and then runs a series of GRANTs to other users, including your developer user to allow the execution of the function.
Now, in order to grant the execute privilege further, the GRANT OPTION* needs to be used in the grant-statement. That is a detail that is usually covered correctly by the HDI infrastructure.
In this case, however, it is clear, that the users that manage HDI 1 do not have the GRANT OPTION to further the privilege to other users.
I recommend reviewing the activation logs, what GRANTS have been declared for the cross-container access, and look out for "missing privilege" errors during activation.
Related
I'm running a SAP HANA database in HDI container and created a corresponding HDI Container admin. I would like to be able to grant users (for support purpose) access not to the whole schema, but only to a few selected tables. How to do it? All examples I found online look like this - and grant access only to a whole schema
CREATE ROLE SCHEMA_NAME.ROLE_NAME NO GRANT TO CREATOR;
GRANT SELECT ON SCHEMA SCHEMA_NAME TO ROLE_NAME;
I know there is an option to use .hdbrole file during deployment, where also object privileges can be written up, but it seems I would have to run deployment each time whenever I need to create a new role. And I would like to create these roles right from the SQL console. Is it possible? And if yes, how to do it?
By running the CREATE ROLE and GRANT commands in the SQL console you create catalog/runtime roles.
These cannot be transported to any other container or DB but only live in this very instance of the database.
Now, that is usually not what you want to have when dealing with HDI containers or containerized applications in general.
Creating schema objects on the fly commonly leads to operational challenges (who has access to what, where, when, why, how?) and should rather be avoided.
But, sure, you can simply connect to the container with any user that has appropriate permissions and run those commands. That includes the usual GRANT SELECT on <table_name> TO <role>; it doesn't have to be the whole schema.
I can unfortunately not provide any code, but I will try to explain as best as I can and will provide additional information as necessary.
There are 3 different schemas at play in this scenario: X_SCHM, APPS, and HR
APPS has a package called X_PKG to run some functionality for a resource, and X_PKG also makes a call to a procedure in package HR_EMPLOYEE_API, owned by HR schema. APPS grants execute privileges on X_PKG to X_SCHM, and X_SCHM can successfully call procedures inside X_PKG.
However, I want to move as much away from APPS and into X_SCHM, so the package body of X_PKG is copied over to a new X2_PKG in X_SCHM. X2_PKG still needs to call a procedure in HR_EMPLOYEE_API, so a grant is given to X_SCHM to execute that package.
Now when X_SCHM tries to call X2_PKG, which is by all accounts identical to X_PKG owned by APPS, it successfully enters HR_EMPLOYEE_API owned by HR and then starts running into "table or view does not exist" errors inside of it, a problem that APPS or X_SCHM running X_PKG owned by APPS does not run into.
I'm not sure if this is an issue of additional grants needing to be made. I would think since X_SCHM has execute privilege on HR_EMPLOYEE_API that procedures it calls from HR_EMPLOYEE_API would be able to access tables owned by HR, unless there's information I'm missing regarding packages needing their own granted privileges separate from the schemas that own them.
Please let me know where I can be clearer or provide more information to get this issue solved.
The package HR_EMPLOYEE_API is defined as AUTHID CURRENT_USER. This means that all the code inside the package is executed as the user who is calling it. So basically you have 3 choices :
1) You leave the package in the APPS User as suggested by #Sudipta Mondal. It sounds like the safest choice.
2) If X2_PKG is defined as AUTHID DEFINER, you could try to copy all the direct rights from APPS to X_SCHM and hope for the best. But it's really not that good because i'm quite sure that APPS has a lot of rights. Luckily you don't have to bother with permissions obtained through roles as they don't apply in packages. try something like that
select 'GRANT '||PRIVILEGE||' ON '||OWNER||'.'||TABLE_NAME||' TO X_SCHM;' FROM DBA_TAB_PRIVS WHERE GRANTEE = 'APPS';
3) Try to figure out which rights to add either by trial and error or by fetching them from DBA_DEPENDENCIES if they are referenced :
select REFERENCED_OWNER, REFERENCED_TYPE, REFERENCED_NAME from dba_dependencies where NAME = 'HR_EMPLOYEE_API';
I, personally, agree with Sudipta Mondal, you should probably reconsider moving it if not mandatory.
I would like to create a user account in SQL Server 2012 with limited access, i.e., he should be only able to run queries and view data and nothing else. No backups, restores, user modifications should be allowed.
I tried looking at the built in server roles, but could not really understand it too well. The Server consists of some 7-8 different databases and we would like this user to have only querying access across all databases and nothing more. Would be great if somebody could guide me as to how to implement it.
Regards
Saurabh
Simple create role and grant access to needed objects with command GRANT. Example:
GRANT SELECT ON TABLE1 TO ROLE_ONLY_VIEW_FOR_EXAMPLE
Then you can assign this role to any user you want.
I have a database on SQL Server 2008 R2 that has two schemas, the default dbo and another one called Webapps, and both schemas are owned by dbo.
I created a view in the Webapps schema (Webapps.getInventory) that just does a simple select from dbo.Inventory. Then I created a user called Webuser that has SELECT permission to the Webapps schema.
Webuser can login and see the Webapps.getInventory view, but when it tries to select from it this error comes up:
The SELECT permission was denied on the object 'Inventory', database 'Database', schema 'dbo'.
I was thinking that since both schemas are owned by dbo, ownership chaining would allow the query to execute. The only way I seem to be able to get it to work is give Webuser permissions on dbo, or add it to the db_datareader role for the whole database. To me that seems to defeat the purpose of trying to separate things out into the Webapps schema if the user has to have read ability to everything else in the database.
So, am I overlooking something in my setup? Or is it correct that Webuser must have permission on both schemas in order for this view to work?
Eric I think you are "jumping" over a step in the ownership chain...
Have (another) look at this article: Ownership Chains Here is a snippet "Ownership chaining enables managing access to multiple objects, such as multiple tables, by setting permissions on one object, such as a view."
The chaining doesn't care that both schemas are owned by dbo, but rather that each login/user has appropriate permissions on object. So if you have a table owned by dbo that is included in a view where you have given select access to the webapps schema, then the users with access should have access to the table. The ownership chain isn't checked deeper than the fact that they can select against the view, no need to evaluate if they can select against the table.
So long story short, if you wrap the dbo.table in a view where webapps has select permissions then you should be good.
Hope that helps...
Another reason that cross-schema ownership chaining may break is if the schema owners were recently changed, e.g. setting them to the same owner specifically in order to use ownership chaining. You may need to drop and recreate the views (and add the permissions back) before it will work.
SQL Server caches various properties of views, and I saw a case where this caching appeared to be causing SQL Server to not realize that an object accessed by the view actually did have the same owner at that point. It gave a "permission denied" error on the object accessed by the view. Dropping and recreating the view fixed the problem. Rebooting the database server might have also fixed it, but that was not an option at the time.
SQL Server also allows individual objects to have specific owners different from the schema owner, and I confirmed that neither the view nor the accessed object had a separate owner set. I saw this in SQL Server 2012. Not sure if it's been fixed in newer versions.
Hello and thank you for your time,
I am using sql 2008
I created a db that has nothing of relevance in. Here I want to add views that access other databases. I will then add a user to the db with no relevance and give access to the view.
My obvious problem is that when the user tries to run the view, errors occur where they do not have permission to view the information. (when I use the admin type user, i can access the view and see the results no problem)
Can I create permissions to the view to all SELECT on the two seperate db's so the user can see the results. Or does the user require the read permissions on all the tables queried.
Thank you again.
This is what I tried (and many others but it did not work)
USE no-relevance-server
GRANT REFERENCES ON OBJECT[important-server::dbo.table] TO [the view]
Your issue here is one of cross database ownership chains
You can make it work by following the instructions at http://support.microsoft.com/kb/810474
EXEC sp_configure 'Cross DB Ownership Chaining', '1'; RECONFIGURE
EXEC sp_dboption 'YourDatabase', 'db chaining', 'true'
But be sure to read up about Cross Database Ownership Chaining and the associated risks.
http://msdn.microsoft.com/en-us/library/ms188676.aspx