CONNECTu' buclucaș

Din ciclul "ha? wtf!", am pațit-o iarăși. Cică mă sună nea clientul să verific dacă schema cutărică are tot ce-i trebuie pentru instalarea unei nu știu ce aplicații obscure. S-ar părea că cei care s-au ocupat de infrastructura lor, înainte de a prelua noi mustăria, pregătiseră puțin terenul, adică facuseră aceste minunate scheme, dar nu era nimeni sigur că ele erau configurate corect.

Întreb: Ce trebuie să fac?
Clientu': Păi verifică dacă "user"-ul se poate conecta și poate crea obiecte de DB! Adică, să aiba rolurile CONNECT și RESOURCE, plus drepturi de CREATE VIEW.
Eu: Atât?
Clientu': Atât!

Buooon, mare vrăjeală îmi zic! Ăsta da "task"! Mă apuc frumușel de verificat.

SQL> select grantee, granted_role
    from dba_role_privs
   where grantee in ('MUCI')
   union
  select grantee, privilege
    from dba_sys_privs
   where grantee in ('MUCI')
   order by 1; 

GRANTEE                        GRANTED_ROLE
------------------------------ ----------------------------------------
MUCI                           CONNECT
MUCI                           CREATE VIEW
MUCI                           RESOURCE
MUCI                           UNLIMITED TABLESPACE

Contactez clientul și îi transmit cu o mică zeflemea în glas: "Am verificat! E în regulă!". După care, din lipsă de altceva interesant, mai bag niște linii de cod în Vorax.

A doua zi primesc mail de la client:

Urgent!!! Am început procesul de instalare, dar primim următoarea eroare:

ORA-01045: user MUCI lacks CREATE SESSION privilege; logon denied

Haaa? WTF! Iau din nou la verificat. Rulez iar SELECT-ul de mai sus, același rezultat. Zic: să vezi că e o mică cretinătate la mijloc și aștia au umblat la rolul CONNECT și i-au scos dreptul de CREATE SESSION. Verificăm:

SQL> select * from dba_sys_privs where grantee='CONNECT';

GRANTEE                        PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
CONNECT                        CREATE SESSION                           NO

Hmmm, nu-i asta! Rolul CONNECT arată bine! Ce-ar mai putea fi? Încerc să nu iau încă în considerare un posibil super-mega-bug. Noroc că îmi amintesc că era o fază cu rolurile. Le puteai activa sau dezactiva din aplicație. Am și folosit treaba asta pentru implementarea sistemului de autorizare folosit de o parte din aplicațiile dezvoltate de FITS, dar era vorba de roluri de aplicație și niciodată nu mi-a trecut prin cap să mă joc cu roluri sistem în felul ăsta.

În fine, s-ar părea că instinctul meu de DBA "bătrân" s-a confirmat:

SQL> SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE='MUCI';

GRANTEE GRANTED_ROLE ADMIN_OPT DEFAULT_R
------- ------------ --------- ---------
MUCI    CONNECT      NO        NO
MUCI    RESOURCE     NO        YES

N-am nici cea mai vagă idee de ce simpaticii dinaintea noastră au configurat în felul ăsta, cert e că, de îndată ce m-am prins despre ce era vorba, soluția a fost simplă ca bună ziua:

SQL> alter user muci default role all;

User altered.

Note: Evident, la client, schema cu pricina nu se chema "MUCI". Orice asemănare cu "personaje" reale e pur întâmplătoare!