Subject:            Role Restrictions
Last Revision Date: 11 September 1994




                         ROLE RESTRICTIONS

This article discusses role restrictions, which are an essential issue in
role implementation.  Most of these restrictions are documented,  however,
some will be documented in the future.

ROLE RESTRICTIONS:

1.  EXTERNALLY IDENTIFIED ROLES CANNOT HAVE AN UNDERSCORE (_) IN ITS NAME
    (VMS SPECIFIC)

When using the operating system to enable roles, i.e. identified externally,
you may not have an underscore in the role's name.  In addition, your SID
cannot have an underscore in its name.  The VMS OSD currently searches for
an underscore to find the "DEFAULT" and "ADMIN" options and would truncate
the role name while loading it from the database.  Thus, the truncated
name will not be granted to the user in the operating system.

    Bugs/Documentation on this issue:
    ---------------------------------
    Bug #145562 - documentation bug.
    Bug #145295 - enhancement request.

2.  USERS CANNOT PERFORM DDL BASED ON PRIVILEGES RECEIVED THROUGH A ROLE.

A user may not create an object using privileges received through a role. For
example, a user cannot create a view based on another's table if he was
granted
the select on this table through a role.  This also applies to procedures,
triggers and references to another user's table.  This restriction will
exist through the duration of the Oracle7 life cycle.

This restriction is necessary because roles can be enabled or disabled
dynamically, making security checking at runtime ambiguous.  For example,
if a user is granted SELECT on a table via a role, enables that role,
creates a procedure to select from the table, and then disables that role,
should the procedure be allowed to execute?  The user still has the
privileges, but they are not currently active. Roles are intended for use
as a tool to administer privileges for end users; they are not intended
for use by application developers.

     Bugs/Documentation on this issue:
     ---------------------------------
     Documented in Oracle7 Server Concepts Manual pg. 18-15.
     Bug #168358 - enhancement request.

3.  A USER CANNOT GRANT 'UNLIMITED TABLESPACE' TO A ROLE OR GRANT IT
    INDIRECTLY THROUGH THE PRE-DEFINED RESOURCE ROLE.

The system privilege 'UNLIMITED TABLESPACE' cannot be granted to a role.
However, the predefined 'RESOURCE' role contains the 'UNLIMITED TABLESPACE'
privilege. If you grant the 'RESOURCE' role to any other role, the 'UNLIMITED
TABLESPACE' privilege will not be transfered to this other role.
For example, if you grant the'RESOURCE' role to another role, i.e., the
accounting role, the user enabling the accounting role will lose the
'UNLIMITED TABLESPACE' privilege, and the user will get an error when trying
to create an object.  This was filed as bug #172360, which is closed as
'not a bug'.  This is a good reason to not use the resource role.

     Bugs/Documentation on this issue:
     ---------------------------------
     Bug #172360 - closed as 'not a bug'.
     Bug #176997 - enhancement request.
     Documented in the Administrator's guide, page 12-6.

4.  ROLES AND PROCEDURES:

When a stored procedure is executed, it is executed under the privileges of
the owner of the procedure without enabling any roles.  Therefore, a select
from the SESSION_ROLES view will return no rows if this query is executed
within a procedure.  Depending on the goal of the procedure, you may be able
to select from DBA_ROLES/USER_ROLES, or possibly use the procedure
IS_ROLE_ENABLED within the DBMS_SESSION package.

     Bugs/Documentation on this issue:
     ---------------------------------
     Bug #135786 - documentation bug.
     Bug #186769 - closed as not a bug.

5.  OSOPER & OSDBA ARE NOT IMPLEMENTED IN ORACLE7 FOR NETWARE:

Unfortunately, these two roles are not implemented in the Netware environment.

At present, both roles are granted only if the user is in the ORACLE_DBA
NetWare group.  It is possible that they will be implemented in V7.1.