Administrace komentářů

jinak by snadno dodatečné kontroly obešel tak, že by příkazy z procedury spustil bez kontrol

To je možné, ale ne vždy něco obejít znamená bezpečnostní riziko. Může to znamenat, že pak budou v databázi nesmysly, bordel, nekompletní informace, atp. Takový stav se pak dá detekovat a ošetřit.

Tedy procedura musí běžet s právy jejího vlastníka, která musí být vyšší, než práva uživatele.

Ne nezbytně; pokud tedy už by měla procedura dělat nějakou privilegovanou činnost, tak patrně budou její práva omezená pouze na tuto jednu činnost. Kód takové procedury bude krátký a doufejme že bez děr. I kdyby díry měla, bude její působnost silně omezena právy.

Např. odeslat košík můžete jen pomocí procedury odesli_kosik, která něco změní v tabulce objednavky, kam normálně nemáte vůbec přístup. Procedura bude mít přístup k tabulce objednavky na připisování ale už nebude mít přístup k Vašemu košíku. Jednoduchý a standardní postup. Porovnejte to s tím, když s vysokými právy k databázi běží tuna PHP kódu (viz níže).

Přesto se to ve spoustě systémů (i v Linuxu) řeší tak, že v jádru běží „vše pod Administrátorem“, a práva se řeší až v uživatelském prostoru.

No a kód samotné databáze také běží jakoby "pod administrátorem" vzhledem k db. Ačkoli se to dá vhodnou separací procesů dost omezit.

A co se týče Linuxu, nikdo neřekl, že jeho monolitický design je state-of-the-art bezpečnosti, spíše naopak. Pokud blbě napsaný driver na USB vařič na kafe, který je součástí všech distribucí, může shodit celé jádro, tak potěš koště. Nerad to říkám, ale vemte si příklad z přístupu, který je použit ve vistě (64), kde v jádře běží podstatně méně ovladačů a zbytek jsou normální procesy...

Nesouvisející kód z tohoto pohledu kontrolovat nemusím

Blbost; dokud lze znásilnit jakýkoliv odlehlý kout Vaší aplikace, máme přístup k master heslu, nebo k běžícímu spojení a tudíž k celé db.

Pokud je někde chyba, která umožní v kontextu aplikace spouštět útočníkův kód, je možnost přístupu do databáze pouze jedním dílčím průšvihem…

Musíte předpokládat, že tam je (můžete se vsadit že tam bude), a musíte se snažit ten průšvih minimalizovat. Bezpečnost musíte řešit na více úrovních, ne jen na přihlašovacím formuláři. BTW zkuste být kreativní: jaké další problémy můžou plynout z takové situace?

než jak se dnes s databázemi běžně pracuje

Prosím Vás, jak kde. "Fórum pro můj kolejní blok" není celosvětové mistrovské dílo. Tam kde o to jde, se databáze používají se vším co umí.

třeba proto, že nepotřebuju jen dělení na jednotlivé uživatele, ale třeba i na jejich session

K čemu je tohle dobré?

„malé“ přihlášení

nebo třeba změna zapomenutého hesla

No, myslím že na oboje by se dalo lamentovat dlouze, ale sečteno podtrženo ani jedno nemá co dělat v aplikaci kde je kladen důraz na bezpečnost dat. Tam je totiž lepší, když něco nejde, a musí to počkat na administrativní zásah, než aby toho šlo víc než bylo původně zamýšleno. Tím ale nechci říct, že taková věc nejde naimplementovat. Uděláte si proceduru, která poběží s právy dostatečnými na reset hesla, konec.