I have an External View from SAP HANA on my SAP ECC system, it's all OK on application servers DEV and QAS, but in PRD I have the error "The type 'XXXX' is unknown." for this line:
DATA: t_table type XXXX.
In PRD, if I go to SE11 and display XXXX, it's all activated with no errors. But I can't do DATA Preview (Authorization Error).
I have other External Views on this system, and it works (SOURCE, DATA PREVIEW, etc).
I already transported a fresh request with objects.
With the limited amount of information in this question all one can do is guess what the problem might be.
My guess is: on your PRD (production) system, the _SYS_REPO user does not have the necessary SELECT-privilege WITH GRANT OPTION but just the SELECT-privilege. That means, the activation can be performed by _SYS_REPO but it cannot grant a SELECT privilege on the activated views back to the SAP<SID>/SAP schema owner user.
If this is the problem the solution is simple: grant the necessary SELECT ... WITH GRANT OPTION to _SYS_REPO and re-activate the transported objects.
Related
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.
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.
Please help me with my case.
We have SAP HANA implemented in our company.
There were few custom roles created based on this doc provided by SAP:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c02c2004-899d-3110-8488-b3ff8362bbf6?QuickLink=index&overridelayout=true&59180354403522.
We have few test users created with different roles assigned (like: transport executor, transport manager). What is the recommended way for testing if these roles are properly configured?
We were thinking about XSUnit, but we have no clue what checks should be performed in order to verify the priviliges.
Is this approach proper?
Checking privileges is a bit tricky.
Since the 'proof of the pudding is the eating' to properly test if your privilege setup is working as expected, you would need to
set up a user
set up your role
assign the role to the user
logon as or impersonate the user so that the role becomes the current role and therefore the current execution privilege setting
try to do whatever the role allows --> this should obviously work
try to do things that shouldn't be possible with the role --> here you should receive the right error messages
tear down everything afterwards
There is nothing build into SAP HANA for that. And depending on what kind of privileges should be tested, it might be difficult to test all of them (dropping tables, deleting DBs, shutting down the system... all that is not easy to contain in a single unit test).
So, I'd recommend to use system views EFFECTIVE_PRIVILEGES and EFFECTIVE_ROLES instead and just check for operations that are allowed once the to be tested role has been granted.
Lars
From what I read so far, the WL 6.1 documentation does not much care of this, and it's assumed that database user ID is SYSADM or something like that. Also, I did not see any explicit explanation what privileges the user ID must have.
While SYSADM is fine for development or staging environment, for production is desired to allow the DB user as less as possible, on the other hand I don't wish to get some exceptions related to weak permissions.
Is there any documentation or other source which explicitly mentions/explains what permissions DB2 user ID must have for Worklight 6.1 datasources?
UPDATE: My understanding is that for WL application work (not install) must be used a separate DB user (mostly for security reason, give as less as possible permissions in production). My question above refers to that "application" DB user. It's clear that create tables and schemas activity can do any DB ID, including SYSADM, which is overkill to further work.
I am asking about DB2 user which configured in WAS datasources, once someone else created DBs, schemas and tables.
The DB2 user used to connect to the datasources need not have any special privileges other than to be able to connect to the Worklight databases. The DB2 user that is used to actually create and initially populate the databases must have SYSADM or SYSCTRL privileges, but these are not needed once the database is set up.
There is more information in the documentation, here: Creating the DB2 databases
The documentation defines the privileges required for a user that can create the tables at install time, upgrade the tables for a new Worklight version and use them at runtime.
At runtime, you need, for each table created: SELECT, UPDATE, INSERT, DELETE. And you need to be able to select a SEQUENCE.
The list of tables and SEQUENCE for Worklight can be found in
/WorklightServer/databases/create-worklight-db2.sql and create--worklightreports-db2.sql
I'm working on a DB2 for i database (aka DB2/400), on a schema (library) named S.
Inside schema S, I create database tables, procedures etc. with user A. I need that also user B has all privileges on such new objects. So I granted all privileges to users A and B on schema S. But new objects don't inherit them!
So I tried many configurations: on System i Navigator I played with authorization lists, "New Objects" button on permissions dialog for schema S... but nothing worked.
How can I set kind of default permissions to be automatically inherited by new objects created in my schema?
The only working alternative I know is remembering to grant privileges to user B every time I create an object. Not so smart...
Security is a large topic. It's normally handled by an administrator; someone who is aware of the larger ramifications of altering permissions to libraries.
There are several related settings to consider. Since you're trying to secure individual objects, you probably have restricted public authority either by setting QSECURITY to *EXCLUDE, or changing the library's CRTAUT to *EXCLUDE.
If we want ALL newly created objects in this library to have the same authority, consider an authorization list. I know that you said you played wuth authorization lists, but you didn't specify what you did.
Create an authorization list. Authorise user A and B to the authorization list. CHGLIB myschema CRTAUT(myautl). Now each object in myschema will have the same authority.
I have IBM i 7.1.
If I create table using 5250 emulator, inside STRSQL, it works, inheriting schema authorization list.
If I create table using iSeries Navigator V5R4M0 (neither with right click on Tables > New > Table, nor with cwbundbs.exe), it doesn't work. Authorization list is not inherited...
So it seems to be a bug in iSeries Navigator. Maybe someone with a newer version of it could confirm us if this has been fixed.
Full details in the chat with #BuckCalabro.