If you take a look at the “alter user” command in the old 9i documentation, you’ll see this:
DEFAULT ROLE Clause
Specify the roles granted by default to the user at logon. This clause can contain only roles that have been granted directly to the user with a GRANT
statement. You cannot use the DEFAULT
ROLE
clause to enable:
- Roles not granted to the user
- Roles granted through other roles
- Roles managed by an external service (such as the operating system), or by the Oracle Internet Directory
Oracle enables default roles at logon without requiring the user to specify their passwords.
And if you do a similar examination of the 10g documentation, its pretty much the same, with some more elaboration.
Specify the roles granted by default to the user at logon. This clause can contain only roles that have been granted directly to the user with a GRANT
statement. You cannot use the DEFAULT
ROLE
clause to enable:
- Roles not granted to the user
- Roles granted through other roles
- Roles managed by an external service (such as the operating system), or by the Oracle Internet Directory
Oracle Database enables default roles at logon without requiring the user to specify their passwords or otherwise be authenticated. If you have granted an application role to the user, you should use the DEFAULT
ROLE
ALL
EXCEPT
role
clause to ensure that, in subsequent logons by the user, the role will not be enabled except by applications using the authorized package.
So lets take a look at the 11.2 documentation for the same section
Specify the roles granted by default to the user at logon. This clause can contain only roles that have been granted directly to the user with a GRANT
statement, or roles created by the user with the CREATE
ROLE
privilege. You cannot use the DEFAULT
ROLE
clause to specify:
- Roles not granted to the user
- Roles granted through other roles
- Roles managed by an external service (such as the operating system), or by the Oracle Internet Directory
- Roles that are enabled by the
SET
ROLE
statement, such as password-authenticated roles and secure application roles
Notice the new 4th bullet point, which has replaced the handling of default roles from previous versions. If a role is password protected, then even if it is set as a default role, then it will not be enabled automatically. We can see this with a simple example:
SQL> conn / as sysdba
Connected.
SQL> create user NO_PRIVS identified by blah;
User created.
SQL> grant create session to NO_PRIVS;
Grant succeeded.
SQL> create role SUPER_DOOPER identified by SECRET_PASSWORD;
Role created.
SQL> create role DOES_NOTHING;
Role created.
SQL> grant delete any table, select any table to SUPER_DOOPER;
Grant succeeded.
SQL> grant SUPER_DOOPER to NO_PRIVS;
Grant succeeded.
SQL> grant DOES_NOTHING to NO_PRIVS;
Grant succeeded.
SQL> alter user NO_PRIVS default role all;
User altered.
SQL> conn NO_PRIVS/blah
Connected.
SQL> select count(*) from hr.employees;
select count(*) from hr.employees
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL>
SQL> set role SUPER_DOOPER identified by SECRET_PASSWORD;
Role set.
SQL> select count(*) from hr.employees;
COUNT(*)
----------
107
SQL>