I have the following situation:
ADMIN_USER - privileged user that can execute whatever he wants and also we use it to deploy scripts to different envs
REGULAR_USER - just a regular schema that holds executable code
I want to create private dblink for REGULAR_USER under ADMIN_USER (while deploying my scripts).
Questions:
Can I achieve this?
If so then what privileges should I give to REGULAR_USER/what actions should I do?
Oracle version is 11gR2
Privileged users can indirectly create database links for other users. The privileged user must temporarily grant the regular user CREATE DATABASE LINK, create a temporary procedure in the regular user's schema that will create the database link, execute that procedure, and then drop the temporary procedure and privilege.
create user regular_user identified by regular_user;
grant create session to regular_user;
grant create database link to regular_user;
create or replace procedure regular_user.create_db_link is
begin
execute immediate
q'[
create database link test_link
connect to regular_user
identified by "regular_user"
using 'orcl'
]';
end;
/
begin
regular_user.create_db_link;
end;
/
drop procedure regular_user.create_db_link;
revoke create database link from regular_user;
To answer your first question: No, you cannot achieve this.
Private database links must be created by the owner of the link. You cannot create a private link in another schema, and you cannot use (directly) a private link in another schema, even as the SYS user. You can use a private link indirectly if there is - for instance - also a view in the other schema which references the link.
So in your case, REGULAR_USER would have to have the CREATE DATABASE LINK privilege, and would have to execute the DDL for the link - ADMIN_USER cannot do it. If ADMIN_USER wanted to use that link, then REGULAR_USER would also have to create a view to reference something on the other end of the link and make the view selectable for ADMIN_USER.
Related
I need to create a custom admin tool, where I create tables and RLS rules outside the Supabase admin dashboard.
Is this possible?
You can use any database interaction tool to do this. I am using a nodejs database migration tool in one of my project along with a nodejs postgres client and I'm able to create tables, enable RLS and write policies with this. You can see all the files doing these tasks in my project here.
Found out in the documentation for RLS, and in combination with the SQL editor (https://supabase.com/docs/guides/auth/row-level-security)
Wrap this bit in a database function with parameters
-- 1. Create table
create table profiles (
id uuid references auth.users,
avatar_url text
);
-- 2. Enable RLS
alter table profiles
enable row level security;
-- 3. Create Policy
create policy "Public profiles are viewable by everyone."
on profiles for select using (
true
);
Then call the function with rpc call
We have an application running on Oracle APEX (ORDS) workspace with parsing schema as "SCHEMA_A"
I have a package "PKG_A1" in schema "SCHEMA_A".
I have a package "PKG_B1" in schema "SCHEMA_B".
I have another package "PKG_B2" in schema "SCHEMA_B" and that package has AUTHID CURRENT_USER clause.
As we know APEX_PUBLIC_USER initiate the session, The call from application to PKG_B2 happens as below:
PKG_A1 --> PKG_B1 --> PKG_B2.
Note: grant execute ON PKG_B1 to schema_A
Question 1: PKG_B2 is executed with SCHEMA_A rights or SCHEMA_B rights or APEX_PUBLIC_USER rights?
Also, if SCHEMA_B has a table "TABLE_B1" exists and a public synonym of a view with the name "TABLE_B1" exists and
PKG_B2 has call to "TABLE_B1" without user alias.
Question 2: will the synonym be called or table is called when called from application?
Please help clarify this
Question 1: PKG_B2 is executed with SCHEMA_A rights or SCHEMA_B rights or APEX_PUBLIC_USER rights?
Answer 1:
As far as I follow you, You want to know if PKG_B2 will be called using SCHEMA_A rights.
It means PKG_A1 --> PKG_B1 --> PKG_B2 will be executed with the following rights respectively.
PKG_A1(SCHEMA_A) --> PKG_B1(SCHEMA_B) --> PKG_B2(SCHEMA_A)
Question 2: will the synonym be called or table is called when called from the application?
Answer 2:
Table from SCHEMA_B is called.
I attempted to create a workspace in APEX using an existing schema called PEOPLE and it gave the error message "The schema is reserved or restricted". I tried with other existing schemas that I created and they all worked fine.
Technical/Environment details follow:
Database: Oracle 19c EE installed on local machine.
Apex: 19.2 installed as Embedded Gateway on local machine.
Created pluggable database called PDB1.
Created tablespace PEOPLE_TAB using OMF (Oracle Managed Files) syntax.
Created local user PEOPLE in PDB1.
Gave PEOPLE the following roles and privs (I'm aware some are doubled up like RESOURCE role and CREATE SESSION priv):
RESOURCE
UNLIMITED TABLESPACE
SELECT_CATALOG_ROLE
CREATE SESSION
CREATE TABLE
CREATE TYPE
CREATE CLUSTER
CREATE TRIGGER
CREATE PROCEDURE
CREATE SEQUENCE
CREATE VIEW
CREATE DIMENSION
CREATE JOB
CREATE SYNONYM
CREATE DIMENSION
CREATE MATERIALIZED VIEW
I created another user TEST1 in the same tablespace PEOPLE_TAB, with the same privs as PEOPLE and re-created the objects and data. I could successfully create a workspace using this new schema!
Trawled the web, but most articles and posts refer to older versions of APEX, but I still tried the following.
I followed the advice given in the Oracle docs, Application Express Release 19.2 Adminstration Guide section 2.13
The APEX engine schema for APEX 19.2 is APEX_190200. So I unlocked APEX_190200 and logged in (after changing password) to run the checks.
-- Checked if PEOPLE was a restricted schema
SELECT schema FROM APEX_190200.wwv_flow_restricted_schemas order by schema;
PEOPLE is not listed and I assume is not restricted. So I tried to unrestrict PEOPLE anyway as detailed in the docs.
-- ran from APEX_190200
EXEC APEX_INSTANCE_ADMIN.UNRESTRICT_SCHEMA(p_schema => 'PEOPLE');
COMMIT;
Successfully ran but did not resolve the issue.
Looking on the web most of the info was out of date but tried anyway.
-- ran from APEX_190200
EXEC APEX_SITE_ADMIN_PRIVS.UNRESTRICT_SCHEMA(p_schema => 'PEOPLE');
COMMIT;
The above did not run and complained the package didn't exist. I verified that when looking for APEX_SITE_ADMIN_PRIVS in user_objects - it was not there.
Some years ago there was a bug with the function wwv_flow_provision.IS_RESERVED, but I checked this and it ran ok returning FALSE for PEOPLE and TRUE for reserved words like VARCHAR.
It's really thrown me when I can create an identical user (different name) with identical privs, objects and data was created on the same tablespace and it worked fine with an APEX workspace.
Does anyone have any experience of resolving this issue or point me in the right direction?
Thank you.
You are receiving the error because PEOPLE is specified as a restricted schema with an APEX package.
In the installation scripts for APEX 19.2, the file named f4050.sql has a page validation on page 79 (the page that is raising the error) that looks like this:
...
...
...
wwv_flow_api.create_page_validation(
p_id=>wwv_flow_api.id(114752711027135415)
,p_validation_name=>'schema not reserved/restricted'
,p_validation_sequence=>80
,p_validation=>wwv_flow_string.join(wwv_flow_t_varchar2(
'wwv_flow_provision.schema_name_valid(',
' p_schema => :F4050_P79_SCHEMA,',
' p_workspace_name => :F4050_P27_COMPANY);'))
,p_validation_type=>'PLSQL_EXPRESSION'
,p_error_message=>'Schema is reserved or restricted'
,p_when_button_pressed=>wwv_flow_api.id(12559200978895311)
,p_error_display_location=>'INLINE_WITH_FIELD_AND_NOTIFICATION'
);
...
...
...
Then using a procedure block like this, you can determine if the schema name is valid or not:
BEGIN
IF apex_190200.wwv_flow_provision.schema_name_valid (p_schema => 'PEOPLE',
p_workspace_name => 'PEOPLE')
THEN
DBMS_OUTPUT.put_line ('Valid');
ELSE
DBMS_OUTPUT.put_line ('Invalid');
END IF;
END;
/
Then by unwrapping the code in those packages (tools can be easily found online). Within that code, there is a call to another function named WWV_FLOW_PROVISIONING.RESERVED_SCHEMA (P_SCHEMA => P_SCHEMA). Within that function, there is code that looks like this:
IF C_SCHEMA IN (
'HTMLDB_PUBLIC_USER',
'APEX_PUBLIC_USER',
'PUBLIC_USER',
'FLOWS_FILES',
'SCHEDULER',
'PEOPLE') THEN
RETURN TRUE;
END IF;
So without modifying the package WWV_FLOW_PROVISIONING (which I would highly recommend AGAINST), you will not be able to create an APEX workspace with the schema name PEOPLE. This will need to be fixed by Oracle either through a patch to the package or in a newer version of APEX.
Fascinating issue. The restricted schema is hard-coded in APEX provisioning code. It's very much a legacy issue.
We can attempt to fix this in the next release of APEX, but that won't help you now. If you file a Service Request for Oracle Support, I'll make sure you get a fix for this issue (assuming you're using a supported version of APEX).
I am new to oracle and using SQL plus terminal to access oracle DB. I tried to create one function and it returned warning that
function created with compilation error
When I executed show errors it always showing
ERROR:
ORA-00942: table or view does not exist
My function :
create or replace function axsaum.get_name
AS
v_name varchar2(20);
begin
v_name:='Helloooooo';
dbms_output.put_line(v_name);
END;
/
Please suggest.
You have the error message: ORA-00942: table or view does not exist. This means your function contains a reference to a database object which the compiler is unable to associate to a table or view within the scope of the function.
There are several reasons why you might get this.
Your function references a table or view which exists in the schema but you have misspelled its name.
Your function references a table or view which exists in a different schema and you have not prefixed the reference with the owning schema and there is no synonym either.
Your function references a table or view which exists in a different schema but the schema owner has not granted you rights on that object.
Your function references a table or view which exists in a different schema and the schema owner has granted you rights on that object through a role. The Oracle security model means that we cannot build database objects (views, stored procedures, etc) using privileges granted to our account through a role. The privileges have to be explicitly granted to our named account.
The object does not exist in your schema or another.
The first two causes are ones you can fix by yourself. The others would require the intervention of the schema owner, or a power user with admin privileges (such as a DBA).
Now that you've posted your function, we can see that you are referencing an Oracle built-in package, DBMS_OUTPUT. Now that package should be installed and granted as part of a default install. But if you have a non-standard install or have accidentally dropped or revoked something you will need to get the SYS user to run the dbmsotpt.sql script which should fix it. The details are covered in the package's documentation. Find out more.
I'm on Oracle 11g, and I do understand the issue of a 3rd-party grant.
But, given that have user1 creating a view "view1" as Select 'foo' from dual.
Then I grant Select on view1 to user2 and I get this error.
But note the "dual" in the view is not qualified as sys.dual, it's just dual. I would think with a synonym public.dual that the actual "dual" used would be public.dual, not sys.dual, so no 3rd party issue should exist because it's public.
And if sys.dual is the one Oracle assumes in this view, one would think that given the use of dual is common in views, and that granting privs on views to other users is also common--wouldn't thousands of users be reporting this issue?
I do see sporadic posts about this but no real solution except to create another copy of dual for the user creating the view, but this doesn't make sense to me.
Thanks for any help.
After consulting our dbas, the issue is an Oracle "Feature" in 11.2.0.4:
TL;DR verison:
As of v 11.0.4, if your View uses Dual, then you can't grant that View anything but SELECT.
Why would we want to grant a view more than Select? In our case the app vendor packaged their updates in such a way that the database portion of the updates automatically scripted full CRUD grants to the master app-schema on every new object, and this included views, because it was simply easier to script that way. This all worked fine until 11.0.4, when Oracle said/enforced "Hey, you can't do that".
Full version:
(Quoted from Oracle site https://support.oracle.com/epmos/faces/BugDisplay?parent=DOCUMENT&sourceId=1628033.1&id=17994036)
Oracle Database - Enterprise Edition - Version 11.2.0.4 to 11.2.0.4 [Release 11.2]
Information in this document applies to any platform.
SYMPTOMS
After upgrading from 11.2.0.3 to 11.2.0.4, you encounter the following error while executing the "create or replace view" statement:
ORA-01720: grant option does not exist
Views were created before the upgrade and "CREATE OR REPLACE VIEW" had worked fine.
CAUSE
The observed behavior is correct. You will get this ORA-1720 error when REPLACING a view that selects from some other user's tables and both of the following conditions are true:
you have already granted select or other privileges on the VIEW to some other user
the view owner does not have the GRANT option on the tables being selected from (or view owner may have some privilege with grant option but not others)
Development has explained it as follows:
The code was changed in 11.2.0.4 so that create view behavior is similar to grant. If you try to make a GRANT on an existing view and the view owner does not have the grant option, then ORA-1720 is the expected result (even in 11.2.0.3). In 11.2.0.4, we have simply made CREATE VIEW consistent with the GRANT behavior, i.e. if an incompatible grant exists, then the new view definition must not be allowed (even with FORCE). In other words, we do not allow incompatible grants to coexist with the view definition and so an error must be thrown. The behavior in release 11.2.0.3 (and earlier) was incorrect; the new behavior in 11.2.0.4 is intentional and correct.
SOLUTION
To avoid this issue, you can do either of the following:
Remove all grants on the view before REPLACING the view. This will ensure that no incompatible grants exist.
Drop and recreate the view. Dropping the view will automatically remove all grants.
REFERENCES
BUG:17994036 - POST UPGRADE TO 11.2.0.4 CREATE OR REPLACE FAILS WITH ORA-01720
BUG:18024486 - ORA-1720 WHEN CREATING VIEW AFTER TO HAVE UPGRADE FROM 11.2.0.3.0 TO 11.2.0.4.0
With sys (as sysdba ) database user grant the necessary privileges, and after that try yo recreate the view with sys (as sysdba ) database user. This was helpful for me.
Regards,
Vase Tusevski