{ "date": "2016-03-16T10:51:38", "slug": "the-privileges-to-connect-to-a-container", "link": "https://www.dbi-services.com/blog/the-privileges-to-connect-to-a-container/", "title": { "rendered": "The privileges to connect to a container" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nIn Multitenant, there are two ways to connect to a pluggable database. This means that if you want to prevent access to a pluggable database you need to revoke two privileges.
\n

\n

Privilege Analysis

\n

Rather than trying with different combination of privileges there is a clever way to do it in 12c with privilege analysis (remember it’s an option).
\nThe idea is to grant all privileges:

\n
\nSQL> create user C##USER1 identified by oracle container=all;\nUser created.\nSQL> grant DBA to C##USER1 container=all;\nGrant succeeded.\n
\n

and then start privilege capture to know which privileges are actually used:

\n
\nSQL> exec dbms_privilege_capture.create_capture (name=>'demo',type =>dbms_privilege_capture.g_role,roles=>role_name_list('DBA'));\nPL/SQL procedure successfully completed.\nSQL> exec dbms_privilege_capture.enable_capture (name=>'demo');\nPL/SQL procedure successfully completed.\n
\n

Note that privilege capture is done per container, so I activate it also in my pluggable database:

\n
\nSQL> alter session set container=PDB001;\nSession altered.\nSQL> exec dbms_privilege_capture.create_capture (name=>'demo',type =>dbms_privilege_capture.g_role,roles=>role_name_list('DBA'));\nPL/SQL procedure successfully completed.\nSQL> exec dbms_privilege_capture.enable_capture (name=>'demo');\nPL/SQL procedure successfully completed.\n
\n

At the end of each operation, I will get the result running this from each container:

\n
\nSQL> exec dbms_privilege_capture.disable_capture(name=>'demo');\nPL/SQL procedure successfully completed.\nSQL> exec dbms_privilege_capture.generate_result(name=>'demo');\nPL/SQL procedure successfully completed.\nSQL> select con_id,username,sys_priv from cdb_used_sysprivs_path;\n
\n

CONNECT

\n

The first way to connect to a pluggable database is to connect directly to its service:

\n
\nSQL> connect C##USER1@//localhost/PDB001.pachot.oraclecloud.internal\nConnected.\n
\n

And, as you expected, the privilege used is the CREATE SESSION in the pluggable database (PDB001 is CON_ID=4) and no privilege at all is needed in CDB$ROOT:

\n
\n    CON_ID USERNAME   SYS_PRIV\n---------- ---------- ----------------------------------------\n         4 C##USER1   CREATE SESSION\n
\n

SET CONTAINER

\n

The second way available to common users only is to connect to CDB$ROOT and then switch to the pluggable database container:

\n
\nSQL> connect C##USER1\nConnected.\nSQL> alter session set container=PDB001;\nSession altered.\n
\n

Of course, we see the CREATE SESSION when connecting to the CDB$ROOT>

\n
\n    CON_ID USERNAME   SYS_PRIV\n---------- ---------- ----------------------------------------\n         1 C##USER1   CREATE SESSION\n
\n

and here is the SET CONTAINER privilege which is used on the pluggable database only.

\n
\n    CON_ID USERNAME   SYS_PRIV\n---------- ---------- ----------------------------------------\n         4 C##USER1   SET CONTAINER\n
\n

Conclusion

\n

If you want to prevent access to a pluggable database from a common user, you need to revoke both SET CONTAINER and CREATE SESSION in that container. Same idea if you want to set some session environment through logon trigger, you may also do it in an AFTER SET CONTAINER trigger.
\nNow, do you think that revoking system privileges is sufficient to prevent C##USER1 from seeing PDB001 data? You should remember that there is another way to see what happens in another container, through the V$ or CDB_ views. Not all data, but lot of information are exposed. The ALTER USER … SET CONTAINER_DATA is there to control that. But that’s for a future post.
\nRemember that a common user can be very powerful in a public or private cloud. You can control what he has access to, but then think of all ways of access.

\n", "protected": false } }