I want to create a view from another view that I have select statement privilege. However, I can't and I am getting this error. Do you know why? Do I need other type of Select privilege?
SET CURRENT SCHEMA = SCHEMA1;
CREATE VIEW NEWSCHEMA.MYVIEW AS SELECT * FROM DB1.SCHEMA1.VIEW1
WITH NO ROW MOVEMENT;
SET CURRENT SCHEMA = NEWSCHEMA;
COMMIT;
full error msg:
Category Line Position Timestamp Duration Message Error 3 0 01/27/2023
11:24:05 AM 0:00:00.007 - DB2 Database Error: ERROR [42501]
[IBM][DB2/AIX64] SQL0551N The statement failed because the
authorization ID does not have the required authorization or privilege
to perform the operation. Authorization ID: "NEWSCHEMA". Operation:
"SELECT". Object: "SCHEMA1.VIEW1".
SELECT GRANTEE, GRANTEETYPE, CONTROLAUTH, SELECTAUTH FROM SYSCAT.TABAUTH WHERE (TABSCHEMA, TABNAME) = ('SCHEMA1', 'VIEW1') AND GRANTEETYPE IN ('U', 'R')
Result:
The reason is highly like because of the following CREATE VIEW authorization requirement:
Authorization
The privileges held by the authorization ID of the
statement must include at least one of the following authorities:
IMPLICIT_SCHEMA authority on the database, if the implicit or explicit schema name of the view does not exist
CREATEIN privilege on the schema, if the schema name of the view refers to an existing schema
SCHEMAADM authority on the schema, if the schema name of the view refers to an existing schema
DBADM authority
and at least one of the following authorities for each table, view, or
nickname identified in any fullselect:
CONTROL privilege on that table, view, or nickname
SELECT privilege on that table, view, or nickname
SELECTIN privilege on the schema containing the table, view, or nickname
DATAACCESS authority on the schema containing the table, view, or nickname
DATAACCESS authority
...
Group privileges are not considered for any table or view specified in the CREATE VIEW statement.
So, you may really have an ability to SELECT from this view, but you probably have it via some group membership, but not personally or via some role.
This is the reason you get this error.
You may ask your SECADM or view owner grant your authorization id a SELECT privilege to resolve the problem.
Related
I want to drop a user who has a mapping to a database scoped credential.
When I use the command
SELECT *
FROM sys.database_scoped_credentials
I see the credentials with the principal_id of the user I want to drop.
How can I change the mapping of the principal_id to the database scoped credential?
When I use the drop command I get the following error message
The database principal has granted or denied permissions to objects in the database and cannot be dropped
It could be the user that you are trying to drop has played a role of grantor and hence you need to revoke those accesses before performing drop of user.
Try running below command to get details of grantee first:
select
permission_name,
state_desc,
object_name(major_id) as securable,
user_name(grantor_principal_id) as grantor
from sys.database_permissions
where grantee_principal_id = user_id('User Name to be dropped')
Next will be to find details on grantor using below:
select *
from sys.database_permissions
where grantor_principal_id = user_id ('User Name to be dropped');
On the basis of the result what you get from above query, you need to perform one of below:
REVOKE VIEW DEFINITION ON USER::User Name to be dropped TO public
REVOKE CONTROL ON USER::User Name to be dropped TO public
REVOKE ALTER ON USER::User Name to be dropped TO public
REVOKE ALTER ON USER::User Name to be dropped TO *grantee*
REVOKE CONTROL ON USER::User Name to be dropped TO *grantee*
REVOKE VIEW DEFINITION ON USER::User Name to be dropped TO *grantee*
Alongwith this, there could be some other type of access which might have been granted. So, you need to check the same and execute revoke accordingly.
Can I use CREATE SCHEMA AUTHORIZATION for something other than the current user's schema?
I can do the following:
CREATE USER MAIN_USER
IDENTIFIED BY main_user_pass;
GRANT CREATE SESSION TO MAIN_USER;
GRANT CREATE TABLE TO MAIN_USER;
ALTER SESSION SET CURRENT_SCHEMA = MAIN_USER;
Query 1:
SELECT USER FROM DUAL;
Result 1:
SYS
Query 2:
SELECT sys_context( 'userenv', 'current_schema') FROM dual;
Result 2:
MAIN_USER
I can do this:
CREATE SCHEMA AUTHORIZATION SYS
CREATE TABLE new_product
(color VARCHAR2(10) PRIMARY KEY);
Result:
Schema AUTHORIZATION created.
But when I try to do this, an error appears:
CREATE SCHEMA AUTHORIZATION MAIN_USER
CREATE TABLE new_product
(color VARCHAR2(10) PRIMARY KEY);
Result:
ORA-02421: missing or invalid schema authorization identifier
02421. 00000 - "missing or invalid schema authorization identifier"
*Cause: the schema name is missing or is incorrect in an authorization
clause of a create schema statement.
*Action: If the name is present, it must be the same as the current
schema.
The error message is pretty clear: you can't do that. From the documentation:
The schema name must be the same as your Oracle Database username.
Setting current_schema only changes the default schema name prepended to an object reference in a SQL command that isn't fully qualified, so after setting it to MAIN_USER, this command:
select * table table_a;
would be interpreted as
select * from main_user.table_a;
instead of
select * from sys.table_a;
Setting current_schema doesn't actually change your logged in identity or affect your privileges in any way, and if sys can't execute a command like that against another schema then nobody can do it.
Can I use CREATE SCHEMA AUTHORIZATION for something other than the current user's schema?
No, you can't. The documentation says:
Use the CREATE SCHEMA statement to create multiple tables and views and perform multiple grants in your own schema in a single transaction.
This statement lets you populate your schema ...
Specify the name of the schema. The schema name must be the same as your Oracle Database username.
You have to be connected as the schema owner, so user returns MAIN_USER. Just changing your current schema with ALTER SESSION SET CURRENT_SCHEMA is not sufficient.
It also says:
To issue a CREATE SCHEMA statement, you must have the privileges necessary to issue the included statements.
and you have granted CREATE TABLE so that should work once you connect as that user. But it means you can't rely on the privileged SYS user's CREATE ANY privs to bypass the schema grants, which might have been an advantage had it been allowed to work as you hoped; if you want your user to end up without those privileges you'll have to grant them, run CREATE SCHEMA as that user, then revoke them again. Or go back to individual CREATE object statements, which you can run for another user as SYS - but without the all-or-nothing single-transaction benefit you get from CREATE SCHEMA.
I have created two new users and a new role. Given select privilege to the role for one table in schema A and assigned this role to user b. While issuing a select query for the table in schema a with this user I am experiencing table or view not found issue.
CREATE USER READUSER1 IDENTIFIED BY readuser1;
CREATE USER READUSER2 IDENTIFIED BY readuser2;
CREATE ROLE READONLY_USER IDENTIFIED BY readonlyuser;
GRANT select ON READUSER1.TESTA TO READONLY_USER;
GRANT READONLY_USER TO READUSER2;
Now from READUSER2 session :
SELECT * FROM READUSER1.TESTA > 00942. 00000 - "table or view does not exist"
I assume that you created the table successfully in the readUser1 schema though you don't show that step.
When logged in as readUser2, what roles are enabled for the session?
select *
from session_roles
I'll wager that the role is not enabled for the session. Normally, you don't set passwords on roles because you normally want those roles to be available to the user as soon as they log in. If you set a password on a role, however, then every time the user creates a new session, they have to explicitly enable the role by specifying the password. That's quite useful in some unusual situations but it's not the norm.
Assuming that readonly_user does not appear in session_roles, you can enable the role using the set role command
set role readonly_user
identified by readonlyuser;
Once you've done that, the role should appear in session_roles and you should be able to query the table.
Normally, though, you'd have created a normal role not a password protected role by omitting the identified by clause
create role readonly_user;
I am working around a workaround to a "feature" in IBM DB2.
This fancy database has a "feature" in it which if I try to use a CREATE TABLE statement and it doesn't find the schema, it will create this schema for me, even if I don't want it to. This bug has caused me a lot of hours in debugging, because my code right now exists with the expectation that it won't create the schema if it doesn't exist
My question is -- how do I change the permissions of a particular schema (or even during the create schema phase) which a particular user does not have access to view?
I checked out this doc..
It seems with GRANT, there are the following three permissions:
ALTERIN
Grants the privilege to alter or comment on all objects in the
schema. The owner of an explicitly created schema automatically
receives ALTERIN privilege.
CREATEIN
Grants the privilege to create
objects in the schema. Other authorities or privileges required to
create the object (such as CREATETAB) are still required. The owner of
an explicitly created schema automatically receives CREATEIN
privilege. An implicitly created schema has CREATEIN privilege
automatically granted to PUBLIC.
DROPIN
Grants the privilege to drop
all objects in the schema. The owner of an explicitly created schema
automatically receives DROPIN privilege
With only ALTERIN, CREATEIN, and DROPIN, I don't see anything relevant to view access permissions :/
EDIT:
I checked out our Dash DB database for this particular table which has these special permissions for particular users using the following SQL:
SELECT * FROM SYSIBMADM.PRIVILEGES WHERE OBJECTSCHEMA = 'FAKE_SCRATCH';
This is the result:
EDIT 2:
I tried the following to emulate Dash DB's permissions for that user for that schema:
GRANT ALTERIN, CREATEIN, DROPIN ON SCHEMA FAKE_SCRATCH TO USER TEST_USER;
Still doesn't work :/
The following SQL query executed in DB2 fixed the problem:
REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC
I need to change owner of table.
I created table:
CREATE TABLE example (some columns);
Then I tried to change owner:
ALTER TABLE database.expample OWNER TO "secondary";
and them I got this error:
ERROR: must be member of role "secondary"
Can anybody help me?
Thanks in advance.
See this from the Postgresql documentation:
http://www.postgresql.org/docs/current/static/sql-altertable.html
You must own the table to use ALTER TABLE. To change the schema of a
table, you must also have CREATE privilege on the new schema. To alter
the owner, you must also be a direct or indirect member of the new
owning role, and that role must have CREATE privilege on the table's
schema. (These restrictions enforce that altering the owner doesn't do
anything you couldn't do by dropping and recreating the table.
However, a superuser can alter ownership of any table anyway.)