Default role with password - reality check

Question

I support the database for an application. We upgraded from Oracle10 to Oracle11 9 months ago. Then recently we applied the OCT CPU.
The application admin says that they have a program that has recently stopped working that worked after the Oracle11 upgrade.
The application user has a default role which has a password. Is that possible? A default role with a password. Would this have ever worked in any version of Oracle?

Answer 1

Default role with password is a feature even available with Oracle XE. Default roles are activated without requiring role password in Oracle 10.2:
SQL> drop user admin cascade;
User dropped.
SQL> drop user test cascade;
User dropped.
SQL> drop role rwp;
Role dropped.
SQL> select * from v$version;
BANNER
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL>
SQL> create user admin identified by oraclexe;
User created.
SQL> grant create session, create table to admin;
Grant succeeded.
SQL> grant unlimited tablespace to admin;
Grant succeeded.
SQL> grant create user to admin;
Grant succeeded.
SQL> grant create role to admin;
Grant succeeded.
SQL>
SQL> create user test identified by oraclexe;
User created.
SQL> grant create session to test;
Grant succeeded.
SQL>
SQL> connect admin/oraclexe;
Connected.
SQL> create table t(x varchar2(10));
Table created.
SQL> insert into t values('admin OK');
1 row created.
SQL> commit;
Commit complete.
SQL> create role rwp identified by oraclexe;
Role created.
SQL> grant all on t to rwp;
Grant succeeded.
SQL> grant rwp to test;
Grant succeeded.
SQL>
SQL> connect test/oraclexe;
Connected.
SQL> select * from session_roles;
ROLE
RWP
SQL> select * from admin.t;
X
admin OK
SQL> insert into admin.t values('test OK');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from admin.t;
X
admin OK
test OK
SQL>There have been changes between Oracle 10.2 and 11.2 because the same script fails in 11.2 unless the role is set with the password:
SQL> drop user admin cascade;
User dropped.
SQL> drop user test cascade;
User dropped.
SQL> drop role rwp;
Role dropped.
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL>
SQL> create user admin identified by oraclexe;
User created.
SQL> grant create session, create table to admin;
Grant succeeded.
SQL> grant unlimited tablespace to admin;
Grant succeeded.
SQL> grant create user to admin;
Grant succeeded.
SQL> grant create role to admin;
Grant succeeded.
SQL>
SQL> create user test identified by oraclexe;
User created.
SQL> grant create session to test;
Grant succeeded.
SQL>
SQL> connect admin/oraclexe;
Connected.
SQL> create table t(x varchar2(10));
Table created.
SQL> insert into t values('admin OK');
1 row created.
SQL> commit;
Commit complete.
SQL> create role rwp identified by oraclexe;
Role created.
SQL> grant all on t to rwp;
Grant succeeded.
SQL> grant rwp to test;
Grant succeeded.
SQL>
SQL> connect test/oraclexe;
Connected.
SQL> select * from session_roles;
no rows selected
SQL> select * from admin.t;
select * from admin.t
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> insert into admin.t values('test OK');
insert into admin.t values('test OK')
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> commit;
Commit complete.
SQL> select * from admin.t;
select * from admin.t
ERROR at line 1:
ORA-00942: table or view does not exist
SQL>
SQL> set role rwp identified by oraclexe;
Role set.
SQL> select * from session_roles;
ROLE
RWP
SQL> select * from admin.t;
X
admin OK
SQL> insert into admin.t values('test OK');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from admin.t;
X
admin OK
test OK
SQL>10.2 Security Guide says:
If you are granted a role protected by a password, then you can enable or disable the role by supplying the proper password for the role in a SET ROLE statement. However, if the role is made a default role and enabled at connect time, then the user is not required to enter a password.
11.1 and 11.2 Secuirty Guide says:
If a user is granted a role protected by a password, then you can enable or disable the role by supplying the proper password for the role in the SET ROLE statement. You cannot authenticate a password-authenticated role on logon, even if you add it to the list of default roles. You must explicitly enable it with the SET ROLE  statement using the required password.
Edited by: P. Forstmann on 20 févr. 2010 10:28