How is the Definer Rights program unit obtaining ALTER SESSION Privilege?

Question

The following is an excerpt from the Oracle 19c Database PL/SQL Language Reference documentation PL/SQL Subprograms 8.14 (emphasis added).

"During a server call, when a DR [DEFINER RIGHT] unit is pushed onto the call stack, the database stores the currently enabled roles and the current values of CURRENT_USER and CURRENT_SCHEMA. It then changes both CURRENT_USER and CURRENT_SCHEMA to the owner of the DR unit, and enables only the role PUBLIC."

select * 
  from dba_sys_privs 
 where     grantee   in ('A', 'PUBLIC') 
       and privilege  = 'ALTER SESSION'
/
-- no rows returned

PUBLIC is not granted ALTER SESSION system privilege.

User A is not granted ALTER SESSION system privilege directly, but is granted ALTER SESSION via a role.

create or replace procedure alter_session
  as
  begin
    execute immediate 'alter session force parallel ddl';
  end;
/

SQL*Plus: Release 19.0.0.0.0 - Production on Sat May 13 20:09:02 2023
Version 19.3.0.0.0

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

Last Successful login time: Sat May 13 2023 20:08:48 -04:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.19.0.0.0

SQL> alter session enable parallel ddl
  2  /

Session altered.

SQL> select pddl_status from v$session where username = 'A'
  2  /

PDDL_STA
--------
ENABLED

SQL> begin
  2    alter_session();
  3  end;
  4  /

PL/SQL procedure successfully completed.

SQL> select pddl_status from v$session where username = 'A'
  2  /

PDDL_STA
--------
FORCED

Even though user A's roles are not used by the definer right PL/SQL program unit's execution (alter_session()), how did user A manage to alter her session via the call to alter_session()?

Answer 1

Every user simply by existing has implicitly certain ALTER SESSION capabilities right out of the box, among them enabling parallel dml, changing a session parameter, etc.. But there are a few ALTER SESSION options that are restricted, like enabling SQL tracing or setting events (because these can have impacts on the server, like generating trace files that fill up disk, etc...). Those require the explicit ALTER SESSION privilege be granted.

Proven:

SQL> create user junk identified by junk;

User created.

SQL> grant create session to junk;

Grant succeeded.

SQL> connect junk/junk;
Connected.
SQL> alter session enable parallel dml;

Session altered.

SQL> alter session set workarea_size_policy='manual';

Session altered.

SQL> alter session set sql_trace=true;
ERROR:
ORA-01031: insufficient privileges


SQL> alter session set events '10046 trace name context forever, level 12';
ERROR:
ORA-01031: insufficient privileges