Archive for category TOI

Getting started with VPD in #Oracle

Virtual Private Database (VPD) aka Fine Grained Access Control may seem complicated at first when you look at the fine documentation about it.

This article gives a short and simple example to get you started easily. The demo below is with 12c Multitenant but works the same with 11g:

SQL> connect reports_owner/reports_owner@pdb1
Connected.
SQL> select * from reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M
Daily report R1 	       D
Daily report R2 	       D

SQL> grant create session to monthly identified by monthly;

Grant succeeded.

SQL> grant select on reports_table to monthly;

Grant succeeded.

SQL> grant create session to daily identified by daily;

Grant succeeded.

SQL> grant select on reports_table to daily;

Grant succeeded.

Say this is a reporting system with a central table that is used for monthly and daily reports. We have separate users for the daily and monthly reports.
Initially, they see both kinds of entries in the table:

SQL> connect monthly/monthly@pdb1
Connected.
SQL> select * from reports_owner.reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M
Daily report R1 	       D
Daily report R2 	       D

SQL> connect daily/daily@pdb1
Connected.
SQL> select * from reports_owner.reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M
Daily report R1 	       D
Daily report R2 	       D

VPD enables both users to keep the same statement but they see only rows for monthly respectively daily frequency:

SQL> connect reports_owner/reports_owner@pdb1
Connected.
SQL> create or replace function frequency_function (schema varchar2, tab varchar2) 
return varchar2 
is
who varchar2(20);
freq char(1);
begin
 select  sys_context('userenv','session_user') into who from dual;
 case who
  when 'MONTHLY' then freq:='M';
  when 'DAILY' then freq:='D';
  else freq:='?';
 end case;

 return 'frequency=''' || freq || '''';
end;
/     

Function created.

SQL> begin
dbms_rls.add_policy(
 object_schema=>'REPORTS_OWNER',
 object_name=>'REPORTS_TABLE',
 policy_name=>'FREQUENCY_POLICY',
 function_schema=>'REPORTS_OWNER',
 policy_function=>'frequency_function');
end;
/   

PL/SQL procedure successfully completed.

SQL> connect monthly/monthly@pdb1
Connected.
SQL> select * from reports_owner.reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M

SQL> connect daily/daily@pdb1
Connected.
SQL> select * from reports_owner.reports_table;

REPORT_NAME		       F
------------------------------ -
Daily report R1 	       D
Daily report R2 	       D

This is possible because VPD silently attaches a WHERE condition to the seemingly unchanged statement:

SQL> connect sys/oracle@pdb1 as sysdba
Connected.
SQL> grant select_catalog_role to monthly;

Grant succeeded.

SQL> connect monthly/monthly@pdb1
Connected.
SQL> select * from reports_owner.reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M

SQL> select plan_table_output from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID	16xw6bqhp67gw, child number 0
-------------------------------------
select * from reports_owner.reports_table

Plan hash value: 2149466028

-----------------------------------------------------------------------------------
| Id  | Operation	  | Name	  | Rows  | Bytes | Cost (%CPU)| Time	  |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |		  |	  |	  |	3 (100)|	  |
|*  1 |  TABLE ACCESS FULL| REPORTS_TABLE |	2 |    38 |	3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("FREQUENCY"='M')


18 rows selected.

The VPD policy adds that WHERE condition depending on the session user. Funny effect:

SQL> connect reports_owner/reports_owner@pdb1
Connected.
SQL> select * from reports_table;

no rows selected

SQL> select plan_table_output from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID	8xc692y0axx0x, child number 0
-------------------------------------
select * from reports_table

Plan hash value: 2149466028
-----------------------------------------------------------------------------------
| Id  | Operation	  | Name	  | Rows  | Bytes | Cost (%CPU)| Time	  |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |		  |	  |	  |	3 (100)|	  |
|*  1 |  TABLE ACCESS FULL| REPORTS_TABLE |	1 |    19 |	3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("FREQUENCY"='?')


18 rows selected.

SYS is not subject to this policy, because of his privilege EXEMPT ACCESS POLICY:

SQL> connect sys/oracle@pdb1 as sysdba
Connected.
SQL> select * from reports_owner.reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M
Daily report R1 	       D
Daily report R2 	       D

SQL> grant exempt access policy to reports_owner;

Grant succeeded.

SQL> connect reports_owner/reports_owner@pdb1
Connected.
SQL> select * from reports_table;

REPORT_NAME		       F
------------------------------ -
Monthly report R1	       M
Monthly report R2	       M
Daily report R1 	       D
Daily report R2 	       D

SQL> select plan_table_output from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID	8xc692y0axx0x, child number 1
-------------------------------------
select * from reports_table

Plan hash value: 2149466028

-----------------------------------------------------------------------------------
| Id  | Operation	  | Name	  | Rows  | Bytes | Cost (%CPU)| Time	  |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |		  |	  |	  |	3 (100)|	  |
|   1 |  TABLE ACCESS FULL| REPORTS_TABLE |	4 |    76 |	3   (0)| 00:00:01 |
-----------------------------------------------------------------------------------


13 rows selected.

So much for starters. Things get more complicated especially if there are no different database users as in the above simplified example. That is usually where an application context is being used – but that could be a topic for another article ๐Ÿ™‚

Leave a comment

Joining Accenture Enkitec Group

I have accepted an offer by the Accenture Enkitec Group to join them starting next month. That unit is a kind of ‘special force’ inside the large Accenture Corporation with particular expertise in Oracle Database and Oracle Engineered Systems technology.

Although I feel quite a bit sad to leave Oracle after all those years, the opportunity to work together with all these bright people – you can see some of them here – outshines that largely ๐Ÿ™‚

 

7 Comments

Common Users in #Oracle 12c – what are they good for?

Common vs Local Users

Common vs Local Users

A 12c Multitenant Database is designed to make consolidation easier. The PDBs have not only their application data in separate tablespaces, they also have their application metadata in separate SYSTEM tablespaces. That’s what makes it so easy and fast to unplug a PDB.

The SYSTEM tablespace of the CDB contains the internal metadata that is shared by all PDBs. Internal metadata (the dictionary tables) and internal objects (like the DBMS* packages) belong to Common Users, most prominently to SYS. We don’t have to install all that internal stuff inside of the PDBs, they can just refer to it.

The point is that Common Users are what enables the Multitenant Architecture in the first place. You as a DBA may also create them as a side aspect of the matter. Now what does that mean in practice?

 

[oracle@uhesse ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.2.0.1.0 Production on Mon Feb 6 11:34:20 2017

Copyright (c) 1982, 2016, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL> select name,open_mode,con_id from v$pdbs;

NAME	   OPEN_MODE	  CON_ID
---------- ---------- ----------
PDB$SEED   READ ONLY	       2
PDB1	   READ WRITE	       3
PDB2	   READ WRITE	       4

My demo system looks like the picture above with two PDBs apart from the seed. Let’s try to clarify the difference between SYS as a common user and SCOTT as two local users.

SQL> connect sys/oracle@pdb1 as sysdba
Connected.
SQL> select common from dba_users where username='SCOTT';

COM
---
NO

SQL> select common from dba_users where username='SYS';

COM
---
YES
SQL> delete from scott.dept where deptno=40;

1 row deleted.

SQL> commit;

Commit complete.

SQL> select * from scott.dept;

    DEPTNO DNAME	  LOC
---------- -------------- -------------
	10 ACCOUNTING	  NEW YORK
	20 RESEARCH	  DALLAS
	30 SALES	  CHICAGO
SQL> connect sys/oracle@pdb2 as sysdba
Connected.
SQL> select common from dba_users where username='SCOTT';

COM
---
NO

SQL> select common from dba_users where username='SYS';

COM
---
YES

SQL> select * from scott.dept;

    DEPTNO DNAME	  LOC
---------- -------------- -------------
	10 ACCOUNTING	  NEW YORK
	20 RESEARCH	  DALLAS
	30 SALES	  CHICAGO
	40 OPERATIONS	  BOSTON

There are two local users with incidentally the same name SCOTT in the two PDBs. The common user SYS is almighty in both PDBs. What common users do we have else visible in the PDBs?

SQL> select username from dba_users where common='YES';

USERNAME
-------------------------------------------------------
SYS
SYSTEM
SYSRAC
SYS$UMF
OUTLN
DBSNMP
APPQOSSYS
CTXSYS
SI_INFORMTN_SCHEMA
GSMADMIN_INTERNAL
ORDPLUGINS
MDSYS
ORDDATA
XDB
WMSYS
ORDSYS
GGSYS
ANONYMOUS
GSMCATUSER
SYSBACKUP
GSMUSER
DIP
SYSKM
ORACLE_OCM
SYSDG
REMOTE_SCHEDULER_AGENT
DBSFWUSER
XS$NULL
OJVMSYS
AUDSYS

30 rows selected.

Apart from SYS and SYSTEM, you see some more internal users on display here. Most of them are related to certain options. This is how these options become available throughout all PDBs. Notice that DBA_USERS shows only what is visible to that PDB. The second SCOTT from PDB2 is not listed, because that user is relevant only for PDB2. It is in other words a local user inside PDB2. CDB_USERS confirms that there are two SCOTT users:

SQL> connect / as sysdba
Connected.
SQL> select con_id,common from cdb_users where username='SCOTT';

    CON_ID COM
---------- ---
	 3 NO
	 4 NO

If you want to create a common user yourself, it must be prefixed with C##. A common user is immediately visible in all PDBs. That doesn’t mean that user has any rights, though.

SQL> connect / as sysdba
Connected.
SQL> create user c##adam identified by oracle container=all;

User created.

SQL> connect sys/oracle@pdb1 as sysdba
Connected.
SQL> select username,common from dba_users where username like 'C##%';

USERNAME   COM
---------- ---
C##ADAM    YES

SQL> connect sys/oracle@pdb2 as sysdba
Connected.
SQL> select username,common from dba_users where username like 'C##%';

USERNAME   COM
---------- ---
C##ADAM    YES

SQL> connect c##adam/oracle@pdb1
ERROR:
ORA-01045: user C##ADAM lacks CREATE SESSION privilege; logon denied


Warning: You are no longer connected to ORACLE.
SQL> connect c##adam/oracle@pdb2
ERROR:
ORA-01045: user C##ADAM lacks CREATE SESSION privilege; logon denied

Common users can get privileges granted as common or as local privileges:

SQL> grant create session to c##adam container=all;

Grant succeeded.

SQL> connect c##adam/oracle@pdb1
Connected.
SQL> connect c##adam/oracle@pdb2
Connected.
SQL> connect / as sysdba
Connected.
SQL> revoke create session from c##adam;
revoke create session from c##adam
*
ERROR at line 1:
ORA-65092: system privilege granted with a different scope to 'C##ADAM'


SQL> revoke create session from c##adam container=all;

Revoke succeeded.

Notice that container=all must be specified upon the revoke as well. That was a common privilege. Now for the local privilege:

SQL> connect sys/oracle@pdb1 as sysdba
Connected.
SQL> grant  create session to c##adam container=current;

Grant succeeded.

SQL> connect c##adam/oracle@pdb1
Connected.
SQL> connect c##adam/oracle@pdb2
ERROR:
ORA-01045: user C##ADAM lacks CREATE SESSION privilege; logon denied


Warning: You are no longer connected to ORACLE.

C##ADAM has the create session privilege only for PDB1, not for PDB2. It is in other words local to PDB1. The clause container=current is optional here and can be left out to achieve the same effect:

SQL> connect sys/oracle@pdb1 as sysdba
Connected.
SQL> revoke create session from c##adam container=current;

Revoke succeeded.

SQL> grant  create session to c##adam;

Grant succeeded.

SQL> revoke create session from c##adam;

Revoke succeeded.

SQL> grant  create session to c##adam container=current;

Grant succeeded.

The two revokes and the two grants have had the same effect. A typical use case for the creation of common users would be to get less powerful superusers like in this example. I would recommend to implement those with some reservation, not to speak about common roles, granting a mixture of local and common privileges to roles and roles to (common) roles. Much is possible but that doesn’t necessarily mean it is a good idea to do it ๐Ÿ™‚

This article is pretty close to what I have presented in Mainz last week during the very well run DOAG Noon2Noon event:

noon2noon_mainz

Only that I was talking in German, which made it a bit easier ๐Ÿ™‚

,

1 Comment

%d bloggers like this: