I am trying to revoke the SELECT privilege for Employee table using the Query
REVOKE SELECT ON ODS_INSTALL.employee FROM ODS_INSTALL;
Currently i am connected in as SYSTEM user, but after getting connected to ODS_INSTALL and firing the query as:
select * from employee;
i am getting the output, but it should give a error regarding insufficient privilege.
What may be the issue?
As in Oracle the schema is the user, as far as I can tell, you cannot REVOKE a privilege on a table from its owner.
Strange you didn't have an error, as on my test system (Oracle 11g):
(as system)
SQL> revoke select on sylvain.n from sylvain
*
ERROR at line 1:
ORA-01927: cannot REVOKE privileges you did not grant
(as sylvain)
SQL> revoke select on n from sylvain;
revoke select on n from sylvain
*
ERROR at line 1:
ORA-01749: you may not GRANT/REVOKE privileges to/from yourself
(issuing a GRANT before does not change anything)
Basically, object privileges are designed to grant/revoke access to your objects from other users. Maybe you should move your table to a dedicated schema, and grant insert/update/delete to ODS_INSTALL in that schema?
If you really really need to restrict access to its own table to an user, the only way I can see is to use Virtual Private Database. Broadly speaking, you will write a function that dynamically generate an extra WHERE clause that Oracle will automagically append to every user query.
CREATE OR REPLACE FUNCTION auth_orders(
schema_var IN VARCHAR2,
table_var IN VARCHAR2
)
RETURN VARCHAR2
IS
return_val VARCHAR2 (400);
BEGIN
RETURN '1=0'; -- always false: "hide" all rows
END auth_orders;
/
And install it using:
BEGIN
DBMS_RLS.ADD_POLICY (
object_schema => 'ODS_INSTALL',
object_name => 'employee',
policy_name => 'orders_policy',
function_schema => 'sys',
policy_function => 'auth_orders',
statement_types => 'select'
);
END;
Take a look at Is to possible to forbid access to tables in own schema - Oracle? [dba se] for some details.
Related
I am attempting to create a package in which I drop and create a table using a CTAS query. This table needs to be refreshed frequently and columns are add/removed all the time from the underlying data. Since the structure of the table is constantly changing, it would be quite cumbersome to update merge/update queries each refresh to account for the new/missing columns. Currently, I have external scripts that do simple drops and creates but I need to centralize this in the database; therefore I am attempting to create a package to do it; however, I am having trouble with privileges.
As proof of concept, the following code works when ran as an anonymous block:
create table my_test_table as select * from dual; --create test table
declare
v_count int;
begin
select count(*) into v_count from all_tab_columns where table_name = upper('my_test_table');
if v_count >= 1 then
execute immediate 'drop table my_test_table';
end if;
execute immediate q'[
create table my_test_table as
select * from dual
]';
end;
select * from my_test_table; -- shows expected results
But when creating a package to do the same thing;
CREATE OR REPLACE PACKAGE test_pkg AS
PROCEDURE test_procedure;
END test_pkg;
CREATE OR REPLACE package body test_pkg as
procedure test_procedure
is
v_count int;
begin
select count(*) into v_count from all_tab_columns where table_name = upper('my_test_table');
if v_count >= 1 then
execute immediate 'drop table my_test_table';
end if;
execute immediate q'[
create table my_test_table as
select * from dual
]';
end test_procedure;
end test_pkg;
/
and testing with the following code:
create table my_test_table as select * from dual; --make sure table exists
execute TEST_PKG.TEST_PROCEDURE; --results in errors
select * from my_test_table; --table does not exist; therefore, DROP statement works but not CREATE
I get the following errors (in regards to executing TEST_PKG.TEST_PROCEDURE):
ORA-01031: insufficient privileges
ORA-06512: at test_pkg, line 15
When testing for the existence of the test table after executing the package, I can see that it no longer exists. This means the DROP statement is working but the CREATE TABLE statement is resulting in the insufficient privileges error.
Any and all insight into what privileges I need to create the table from within the package would be immensely helpful.
Create a table in procedure is only alowed when you have "Create table" or "create any table" privilege but granted directly to user (granted by role is not working).
https://docs.oracle.com/cd/B19306_01/network.102/b14266/authoriz.htm#i1008334
PL/SQL Blocks and Roles
The use of roles in a PL/SQL block depends on whether it is an
anonymous block or a named block (stored procedure, function, or
trigger), and whether it executes with definer's rights or invoker's
rights.
Named Blocks with Definer's Rights
All roles are disabled in any named PL/SQL block (stored procedure,
function, or trigger) that executes with definer's rights. Roles are
not used for privilege checking and you cannot set roles within a
definer's rights procedure.
To check system privileges granted directly to your user (not by role/roles), you can run this query from your user:
SELECT * FROM USER_SYS_PRIVS;
The package you've created, in the absence of a AUTHID CURRENT_USER clause is a definer's rights package. It can only do things that are allowed by privileges granted directly to the definer of the package. "Directly" is the key point here -- privileges granted through enabled roles are not honored during the package execution.
You've probably got the RESOURCE or similar role enabled for your user, which would explain why you can create the table during testing but not via your package procedure.
Try granting the CREATE TABLE and UNLIMITED TABLESPACE system privileges directly to your user and then recreate the package. (If that works, replace UNLIMITED TABLESPACE with quotas on the appropriate tablespace(s) in your database).
I need to grant permission to a specific user to create stored procedures in PostgreSQL without writing permissions to other tables. The stored procedure should read and write only in one table.
I've already setup the read permission to that table, but I'm struggling with the writting permissions.
GRANT CONNECT ON DATABASE production_database TO user;
GRANT USAGE ON SCHEMA public TO user;
GRANT SELECT ON table TO user;
If you want to write a procedure in PL/PGSQL you need to use PostgreSQL 11 or 12.
In PostgreSQL there is no explicit privilege to create a procedure or a function.
However you can try:
to create a specific schema just for the procedure
to grant USAGE to this schema only to the specific user
to create the procedure with SECURITY DEFINER as the table owner
Example:
create user myuser password 'myuser';
--
create table public.t(x int);
--
create schema myschema;
--
create or replace procedure myschema.myproc(param int)
language plpgsql
as
$$
declare
v int;
begin
insert into public.t values(param);
end;
$$
security definer
set search_path='';
--
grant usage on schema myschema to myuser;
Here the table owner is superuser postgres and the table schema is public:
With this script:
\c postgres myuser
select * from t;
call myschema.myproc(1);
\c postgres postgres
select * from t;
I get:
You are now connected to database "postgres" as user "myuser".
select * from t;
psql:cp.sql:25: ERROR: permission denied for table t
call myschema.myproc(1);
CALL
You are now connected to database "postgres" as user "postgres".
select * from t;
x
---
1
(1 row)
I'm looking for a quick easy way to revoke every privilege a user has to tables, views, etc. Is there any simple magic that can do this?
The purpose of doing this is to start fresh on what access should have.
When you find out which privileges user has, e.g.
SQL> select * From user_sys_privs;
USERNAME PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
SCOTT CREATE DATABASE LINK NO
SCOTT CREATE ROLE NO
SCOTT CREATE VIEW NO
SCOTT CREATE TYPE NO
SCOTT CREATE PROCEDURE NO
SCOTT UNLIMITED TABLESPACE NO
SCOTT CREATE PUBLIC SYNONYM NO
SCOTT CREATE TABLE NO
SCOTT CREATE TRIGGER NO
SCOTT CREATE SEQUENCE NO
SCOTT CREATE SESSION NO
11 rows selected.
SQL>
then write query which will write some code for you:
SQL> select 'revoke ' || privilege || ' from scott;'
2 from user_sys_privs;
'REVOKE'||PRIVILEGE||'FROMSCOTT;'
--------------------------------------------------------
revoke CREATE DATABASE LINK from scott;
revoke CREATE VIEW from scott;
revoke CREATE ROLE from scott;
revoke UNLIMITED TABLESPACE from scott;
revoke CREATE PROCEDURE from scott;
revoke CREATE TYPE from scott;
revoke CREATE PUBLIC SYNONYM from scott;
revoke CREATE TABLE from scott;
revoke CREATE TRIGGER from scott;
revoke CREATE SESSION from scott;
revoke CREATE SEQUENCE from scott;
11 rows selected.
SQL>
Now copy/paste those revoke statements and run them.
However, that's not all. User can have additional privileges, so - as a privileged user - query DBA_SYS_PRIVS, DBA_ROLE_PRIVS, DBA_TAB_PRIVS.
In order not to think too much :), have a look at how Pete Finnigan did that. Script dates from 2003, but - it'll give you idea how to do it.
Also, probably the simplest way to do it would be to drop that user (but that's, I suppose, not an option).
I kept thinking there was some sort of REVOKE ALL command
Alas, no. Privileges are revoked (and granted) atomically, which is the way it should be. Wanting to revoke all privileges from a user is a product of the same mindset which lead to granting too many and/or too powerful privileges in the first place.
There are three classes of granted privilege:
role
system (CREATE TABLE, CREATE SESSION, etc)
object access (tables, views, procedures etc in other schemas)
Each has a different set of views over the data dictionary.
USER_ROLE_PRIVS ( also ALL_, DBA_ )
USER_SYS_PRIVS ( also ALL_, DBA_ )
USER_TABLE_PRIVS ( also ALL_, DBA_ )
We can use these views to generate REVOKE statements. It seems peculiar to do this as the user in question. So, a a power user (i.e. a DBA) execute something like this:
begin
dbms_output.put_line('Revoking granted roles ...');
for r in ( select * from dba_role_privs
where grantee = 'JOESOAP' )
loop
dbms_output.put_line('revoke ' || r.granted_role ||' from ' || r.grantee ||';');
end loop;
dbms_output.put_line('Revoking granted system privileges ...');
for r in ( select * from dba_sys_privs
where grantee = 'JOESOAP' )
loop
dbms_output.put_line('revoke ' || r.privilege ||' from ' || r.grantee ||';');
end loop;
dbms_output.put_line('granted access privileges ...');
for r in ( select * from dba_tab_privs
where grantee = 'JOESOAP' )
loop
dbms_output.put_line('revoke ' || r.privilege || ' on ' || r.owner||'.'||r.table_name ||' from ' || r.grantee ||';');
end loop;
end;
/
This will output commands to the screen - use an IDE like SQL Developer to make this less tricky - which you can review and save as an executable script. I suggest you do this rather than have the loops EXECUTE IMMEDIATE simply because you need to have a record of what privileges you've zapped, and also to stop you accidentally de-authorising something or somebody which might come back to bite you later.
In fact, rather than revoking all privileges and re-granting some of them it would be better to see all the privileges the user has and just revoke the ones which shouldn't have been granted.
We're rationalising our database user permissions and to that end we'd like to revoke all select permissions across all tables in a schema granted to all users (but not a specific role).
With some regular expressions I've tried creating a universal revoke for each table giving something like:
revoke select on TABLE1 from USER1,USER2,USER3...;
revoke select on TABLE2 from USER1,USER2,USER3...;
However as not all users were granted permissions to all tables, this results in the oracle error:
01927. 00000 - "cannot REVOKE privileges you did not grant"
Which makes sense but isn't helpful.
I also tried using All_Tab_Privs to get a list of all tables with the requisite grants to be revoked, and this works, but I can't see how to easily get from this to actually revoking the permissions.
SELECT * From All_Tab_Privs where grantor = 'GRANTING_USER' and grantee != 'READROLE' and grantee != 'PUBLIC' and grantee != 'SYS';
Any suggestions for how to do this without spending hours in a spreadsheet? I'm guessing some PL/SQL? Thanks.
A general pattern for this kind of job is to use an implicit cursor to return the data you want and then to build the DDL and execute them.
begin
for x in (select attribute_1, attribute_2 ... from ... where ...)
loop
execute immediate 'REVOKE ...'||x.attribute1||' etc';
end loop;
end;
/
A nice alternative is to build the SQL you want to execute in the SELECT and then just execute that. It's easier to test but the SQL then looks a bit clunky.
-- Revoke Privs Granted to Users
BEGIN
FOR r IN (SELECT * FROM all_tab_privs WHERE grantee IN ('USER_1', 'USER_2'))
LOOP
EXECUTE IMMEDIATE 'REVOKE '||r.privilege||' ON '||r.table_name||' FROM '||r.grantee;
END LOOP;
END;
/
Some PL/SQL and dynamic SQL:
begin
for r in (SELECT * From All_Tab_Privs
where grantor = 'GRANTING_USER'
and grantee != 'READROLE'
and grantee != 'PUBLIC'
and grantee != 'SYS')
loop
execute immediate 'revoke '||r.privilege||' from '||r.grantee;
end loop;
end;
I had a quite interesting situation on my database. Oracles own SQL Developer still listed the existing grants for each table, although they were gone from the all_tab_privs table (a SELECT brought no result for the searched grantees).
I've fixed that by using the following construct:
BEGIN
FOR r IN (SELECT owner, table_name FROM dba_tables WHERE owner IN ('owner1', 'owner2'))
LOOP
EXECUTE IMMEDIATE 'REVOKE ALL ON '||r.owner||'.'||r.table_name||' FROM grantee1, grantee2';
END LOOP;
END;
/
This first selects all owners and table names from each table of certain owners. Then it revokes all grants for certain grantees.
The good thing is, that this won't fail if there aren't any grants for one of the listed grantee for one of the selected tables.
Mind that this should be executed from an administrator account, like system, so the current user has the right to revoke grants for tables of another user.
I am trying to access information from an Oracle meta-data table from within a function. For example (purposefully simplified):
CREATE OR REPLACE PROCEDURE MyProcedure
IS
users_datafile_path VARCHAR2(100);
BEGIN
SELECT file_name INTO users_datafile_path
FROM dba_data_files
WHERE tablespace_name='USERS'
AND rownum=1;
END MyProcedure;
/
When I try to execute this command in an sqlplus process, I get the following errors:
LINE/COL ERROR
-------- -----------------------------------------------------------------
5/5 PL/SQL: SQL Statement ignored
6/12 PL/SQL: ORA-00942: table or view does not exist
I know the user has access to the table, because when I execute the following command from the same sqlplus process, it displays the expected information:
SELECT file_name
FROM dba_data_files
WHERE tablespace_name='USERS'
AND rownum=1;
Which results in:
FILE_NAME
--------------------------------------------------------------------------------
/usr/lib/oracle/xe/oradata/XE/users.dbf
Is there something I need to do differently?
Make sure that SELECT is not only grantet through a role, but that the user actually has the grant. Grants by roles do not apply to packages. See this post at asktom.oracle.com.
Also, try sys.dba_data_files instead of dba_data_files.
Specify WITH GRANT OPTION to enable the grantee to grant the object privileges to other users and roles.
GRANT SELECT ON dba_data_files TO YOUR_USER WITH GRANT OPTION;
Have you tried prefixing the table name with sys. as in
FROM sys.dba_data_files
For selecting data from dba_data_files, grant select from SYS user to USER. Example:
GRANT SELECT ON dba_data_files TO YOUR_USER;
After that recompile your Procedure.