SQLite Data Studio: pravice

Nazaj: SQLite Data Studio

Kdo sme v studiu kaj, določa model zmožnosti, ki ga uveljavlja strežnik: branje, pisanje, oblikovanje in upravljanje so ločene pravice, dodeljene globalno ali za posamezno povezavo.

[Live] Podroben model pravic, ki ga uveljavlja strežnik – skupine in uporabnike DokuWikija preslika na zmožnosti v studiu. Ni nadomestilo za ACL strani: pravilnik ureja izključno funkcije studia, nikoli bralnega dostopa do strani wikija.

Pri vsakem preverjanju PolicyGate::isAllowed($capability, $conn, …) velja prvo pravilo, ki se ujema, in sicer v tem vrstnem redu:

1. Izjema za superuporabnike – vedno dovoljeno, ne glede na pravila v matriki. Tudi pri neznani ali napačno zapisani zmožnosti se najprej preveri, ali zmožnost sploh obstaja: programska napaka z izmišljenim imenom zmožnosti niti za superuporabnika ne sme po pomoti vrniti »dovoljeno«.
2. dbadmin_readonly=1 write in design vedno postavi na prepovedano, tudi če bi ju matrika dovolila – naslednja pravila tega nikoli ne obidejo.
3. Pravilo za povezavo ima prednost pred globalnim; znotraj istega obsega ima pravilo za natančno uporabniško ime prednost pred vsakim pravilom @skupina. Če pravila za uporabnika ni, se več ujemajočih pravil za skupine istega obsega združi.
4. Sicer je dostop zavrnjen.

Pogovorno okno Matrika zmožnosti se odpre na dva načina: Pravice… v ukazni vrstici območja Povezave (globalni obseg) ali Pravice v meniju Dejanja pri povezavi v raziskovalcu objektov (obseg te povezave). Vrstice so skupine in uporabniki v zapisu iz acl.auth.php (začetni @ pomeni skupino), stolpci šest zmožnosti, preklopnik pa izbere obseg (globalno ↔ posamezna povezava).

• Podedovano ali lastno pravilo: v obsegu povezave vrstica brez lastnega pravila za povezavo prikaže podedovano globalno vrednost (zatemnjeno, z značko podedovano); lastno pravilo za povezavo globalno vrednost za ta subjekt v celoti nadomesti (globalno in lastno se ne združita).
• Odstranitev vrstice poteka prek istega pogovornega okna s potrditvijo v dveh korakih kot vsako drugo uničujoče dejanje v studiu – odstranitev pravila lahko takoj spremeni, kaj uporabnik sme.
• Hramba: conf/wksqliteds.policy.json, atomaren zapis in .bak, brez skrivnosti.
• Napačen ali poškodovan policy.json se varno zapre na prazno matriko (zavrnitev za vse razen superuporabnikov), namesto da bi sprožil napako ali prevzel delno zaupanja vredne podatke.

1. Stopnja 1 (zaključena): privzeti pravilnik »samo superuporabniki« – vedenje enako kot prej; vmesnik matrike in preverjanje sta delovala, dejansko pa nista spremenila ničesar, dokler pravilnika nihče ni razširil.
2. Stopnja 2 (zaključena, po dokumentiranem varnostnem pregledu): meni studia in vsak vstop v območje sta vezana na pravilnik. Uporabnik, ki ni superuporabnik in ima vsaj eno zmožnost, vidi meni studia in lahko naredi natanko to, kar dovoljujejo njegovi vnosi v matriki; neposredna povezava na prepovedano območje prikaže nevtralno stran z zavrnitvijo brez notranjih podrobnosti (brez imena zmožnosti in brez imena povezave). Vidnost se filtrira na ravni območij in zavihkov (Povezave, zbirka podatkov, Rutine), ne na ravni posameznih gumbov v območju, ker preverjanje na strežniku vsako dejansko spremembo tako ali tako v celoti prepreči (vidnost v vmesniku nikoli ni edina zaščita).

• Vdelani PHP v rutinah ostane ne glede na dovoljenje v matriki vezan na prave superuporabnike (tudi če sta dodeljena design ali use) – podrobnosti: Rutine → model groženj za vdelani PHP.
• Končna točka AJAX za pomožno vrstico poleg prijave, žetona seje in preverjanja ACL zahteva še zmožnost query – enak vrstni red (dodatno, nikoli namesto) velja za vsako točko razvejanja.
• Sprememba prijave ali skupin učinkuje takoj: razreševanje ob vsaki zahtevi znova prebere uporabniško ime in skupine, rezultata, shranjenega med prijavami, ni.
• Zavrnjeni poskusi dostopa se zabeležijo (uporabnik, zahtevana zmožnost in povezava, nikoli vsebina poizvedbe) – namenoma na ravni dnevnika debug, da ob vklopljenem dušenju dnevnika (obratovanje na exFAT) ne pomenijo dodatne obremenitve.

[Live] Zgornja matrika odgovori na vprašanje kdo ste, in to iz seje. Ne odgovori pa na vprašanje ali ste to še vedno vi. Prevzeta seja – ukraden piškotek, delovna postaja brez nadzora – ima na tem zaslonu enake pravice kot lastnik računa.

Za tri zmožnosti z največjim dosegom studio zato zahteva še drugi dejavnik, nedavno dokazan v tej seji. Dokaz poteka prek pogodbe Identity Plugin Contract v1 (opis pogodbe) in je zgolj dodaten: ne nadomesti niti ACL strani niti matrike, temveč se jima pridruži kot tretja vrata.

Pod te kategorije spada štirinajst dejanj: routine_create, routine_save, routine_save_props, routine_delete · conn_create, conn_save, conn_delete · db_table_drop, db_view_drop, db_rows_delete, db_import_run, db_restore_run, db_optimize, db_backup_delete.

• Vsako bralno dejanje – routine_test, conn_test, db_export, db_sql_run, db_check_syntax, db_integrity_check in vsak predogled. Ničesar ne spremenijo.
• Urejanje posameznih vrstic in sama matrika zmožnosti. To je vsakdanje delo na tem zaslonu.

Razlog ni udobje: delovno okolje, ki pred vsako poizvedbo zahteva kodo, ljudje izklopijo, namesto da bi ga uporabljali – dejavnik, ki se zahteva ves čas, pa postane formalnost in nato ne ščiti ničesar več.

• Oddana dejanja preveri admin.php::handle(), še pred razvejanjem. Action\Admin::preProcess() pokliče handle() pred vsakim izpisom – preusmeritev na poziv je tam mogoča.
• Pot izrisa tega ne zmore: teče sredi strani, preusmeritev od tam pa tiho spodleti. Zato obstaja most do=wksqliteds_stepup, samostojna zahteva, ki odloči pred vsakim izpisom.

Tabela dejanj je zapisana natanko enkrat, v StepUpBridge; admin.php jo bere prek categoryForAction(). Ta paket je za tabelo, ki se je oddaljila od lastnega razdelilnika, plačal že trikrat – nabor testov zato obe smeri preverja drugo proti drugi.

Če paket za identiteto ni nameščen, je odgovor dovoljeno in zaslon se vede natanko tako kot prej. To je namerno odprto ob odpovedi: pogodba je dodatek k seznamu dostopa, manjkajoči dodatni paket pa ne sme zakleniti zaslona, ki je prej deloval.

Račun z nameščenim paketom, a brez vpisanega dejavnika dobi sporočilo stepup_denied (To dejanje zahteva drugi dejavnik. Za ta račun ni vpisan noben, s katerim bi ga bilo mogoče dokazati …). Pove, kaj manjka, namesto da bi zahtevalo »dokažite zdaj«: kdor bi zahtevo lahko izpolnil, je preusmerjen na pravi poziv in tega sporočila nikoli ne vidi.

• Skrbniški vmesnik – katero območje ali zaslon zahteva katero zmožnost
• Povezave – upravljanje povezav zahteva admin
• Rutine – posebni primer vdelanega PHP
• Identity Plugin Contract v1 – pogodba, prek katere se dokaže drugi dejavnik