PHP variabele gebruiken in PgSQL functie

[Verwijderd]

Hai,

Wij zijn bezig een CMS systeem te bouwen in PHP. Als database maken we gebruik van PostgreSQL 8.0.1. We willen graag dat een zo groot mogelijk deel van het 'rechtenverhaal' wordt geregeld door de database zelf.
Dus als er bijvoorbeeld een element wordt verwijderd, dan zal er (ik noem maar wat) met een trigger 'gekeken' worden of deze gebruiker deze actie mag uitvoeren.

Om deze oplossing uit te voeren moet het user_id van de gebruiker die aan het werk is wel bekend zijn in de database. Als er een delete query wordt uitgevoerd geef je op geen enkele manier een user_id ofzo mee...

Hoe zou ik ervoor kunnen zorgen dat de database 'weet' welke gebruiker er bezig is? Ik heb al zitten denken aan een aparte tabel waar steeds maar 1 rij in zit. En dan voer je aan het begin van je script het user_id daar in en aan het einde gooi je het weer leeg. Het probleem is echter dat PHP scripts parallel kunnen worden uitgevoerd. Meerdere gebruikers kunnen tegelijk hetzelfde PHP script laten draaien. Hierdoor werkt mijn plannetje mooi niet.

Heeft iemand een geniale oplossing?

[Michali]

Ik zou dat gewoon helemaal anders aanpakken. Je laat de database toch niet controleren of je de gebruiker wel bepaalde acties mag uitvoeren? Dat kun je eventueel als 2de laag houden voor de zekerheid, maar je gooit dat toch gewoon helemaal dicht zodat een gebruiker die actie niet eens ziet als hij daar geen recht toe heeft? Ik zou hier nog eens goed over na gaan denken, het klinkt niet erg doordacht eerlijk gezegd.

[rb338]

Vraag: waarom zou je een database functies gaan geven die het niet hoort te hebben?
M.a.w, een database is, zoals de naam doet vermoeden, een applicatie om gegevens op te slaan. Het nakijken van permissies etc. zou daar compleet los van moeten staan.

Daarnaast betwijfel ik sowieso of dit wel kan met PgSQL.

[ Voor 4% gewijzigd door rb338 op 04-04-2005 15:40 ]

[Verwijderd]

Mee eens. Het enige wat je een database kan laten doen, is dat als je niet inlogd, je enkel leesrechten hebt, en als je ingelogd bent, dat hij dan naar de database connect met r/w rechten.

Verder kun je wel met GRANTS gaan werken, maar over het algemeen wil je dat *echt* niet aan je DBMS overlaten, dat kun je veel beter afvangen in programmalogica.

edit:
Al kun je natuurlijk wel een losse tabel hebben met userid en object wat je wil wijzigen, en dat je alleen een query uitvoert als er uit voorgaande query is gebleken dat je dat mag.
Dan doe je wel 2 queries na elkaar, wat je meestal niet wilt, maar voor dit soort doeleinden zal het niet zo'n erg grote performance impact geven.

[ Voor 33% gewijzigd door Verwijderd op 04-04-2005 16:25 ]

[Verwijderd]

Verwijderd schreef op maandag 04 april 2005 @ 16:23:
Mee eens. Het enige wat je een database kan laten doen, is dat als je niet inlogd, je enkel leesrechten hebt, en als je ingelogd bent, dat hij dan naar de database connect met r/w rechten.

Verder kun je wel met GRANTS gaan werken, maar over het algemeen wil je dat *echt* niet aan je DBMS overlaten, dat kun je veel beter afvangen in programmalogica.

Complete onzin, opzich is het idee van TS een hele degelijke, je bent in een keer van de problemen als "SQL injection" af. Het voorkomt juist foutgevoelige progmatische oplossingen. Hier is juist iemand bezig die WEL over een probleem heeft nagedacht.

je kunt gewoon gewoon een "grant delete" uitvoeren op een column per gebruiker...

[Michali]

Verwijderd schreef op maandag 04 april 2005 @ 16:53:
[...]

Complete onzin, opzich is het idee van TS een hele degelijke, je bent in een keer van de problemen als "SQL injection" af. Het voorkomt juist foutgevoelige progmatische oplossingen. Hier is juist iemand bezig die WEL over een probleem heeft nagedacht.

je kunt gewoon gewoon een "grant delete" uitvoeren op een column per gebruiker...

Uiteraard. Maar je geeft de gebruikers toch niet de mogelijkheid om een delete actie uit te voeren om vervolgens de melding te geven dat ie dat niet mag? Lijkt me dat die optie dan gewoon verborgen of uitgeschakeld moet worden. Als 2de controle is het zeker een goed idee, maar puur hierop leunen is niet goed iig.

[ Voor 3% gewijzigd door Michali op 04-04-2005 17:02 ]

[djluc]

Sowieso is het natuurlijk erg lastig om dit alles geheel portable te houden. Verder ben je gebonden aan het rechtensysteem van de database. Je moet je afvragen of dit voldoende is voor de applicatie anders moet je ook nog een 2e rechtensysteem hebben waar je de overige rechten mee beheert. Dan heb je dubbel werk.

[eamelink]

Verwijderd schreef op maandag 04 april 2005 @ 16:53:
[...]

Complete onzin, opzich is het idee van TS een hele degelijke, je bent in een keer van de problemen als "SQL injection" af. Het voorkomt juist foutgevoelige progmatische oplossingen. Hier is juist iemand bezig die WEL over een probleem heeft nagedacht.

Je voorkomt hier absoluut geen SQL injection mee; door een injection wordt je query gewijzigd, en hij wil in de query bepaalde checks meegeven. Als de query gewijzigd wordt doen die het niet meer.

je kunt gewoon gewoon een "grant delete" uitvoeren op een column per gebruiker...

Gebruiker website != gebruiker database.

Of wil je soms per hit eerst gaan kijken op welke tables de gebruiker van die pagina wel of niet zou mogen zitten, dan alle table permissies wijzigen, en dan aan het einde van de request weer goedzetten? Dat lijkt me _tamelijk_ inefficiënt.

[raptorix]

rb338 schreef op maandag 04 april 2005 @ 15:40:
Vraag: waarom zou je een database functies gaan geven die het niet hoort te hebben?
M.a.w, een database is, zoals de naam doet vermoeden, een applicatie om gegevens op te slaan. Het nakijken van permissies etc. zou daar compleet los van moeten staan.

Daarnaast betwijfel ik sowieso of dit wel kan met PgSQL.

LOL, ehhhhhhhhm
Dat sommige (crap) databases dat niet aankunnen wil nog niet zeggen dat het geen functionaliteit is die in een database hoort, je kan wel twijfelen of het slim is om integraal met elke user ook een database user aan te maken (imo zou je dat kunnen doen met standalone applicaties waarbij de connectie direct vanaf de client gemaakt wordt).

Bovendien kan je stellen dat de 4e regel van Codd dit zelfs verplicht stelt:

Dynamic online catalog based on the relational model. The database description is represented at the logical level in the same way as ordinary data, so that authorized users can apply the same relational language to its interrogation as they apply to the regular data.

[ Voor 20% gewijzigd door raptorix op 04-04-2005 17:56 ]

[Verwijderd]

Je kan toch de hele boel opzetten met grants en dan in je pg_connect inloggen als de betreffende gebruiker? Sowieso regelt postgres dan de toegang tot tabellen of views en wat je daarop mag los laten en mocht je het nodig vinden (bv binnen een trigger of stored procedure) te weten welke gebruiker er op dit moment bezig is, bestaan er dacht ik functies binnen posgres die de naam terug geven van de huidige gebruiker... Verder lijkt het me niet nodig om met extra tabellen te werken. Het is gewoon een feature van een "hedendaagse" db...

Nadeel is dat een gebruiker van je CMS ook een user binnen postgres moet zijn, maar verder lijkt me dit niet echt moeilijk... Of ik moet je vraag verkeerd hebben begrepen...

PS: Groeten aan marijn

[Verwijderd]

eamelink schreef op maandag 04 april 2005 @ 17:29:
Je voorkomt hier absoluut geen SQL injection mee; door een injection wordt je query gewijzigd, en hij wil in de query bepaalde checks meegeven. Als de query gewijzigd wordt doen die het niet meer.

Je kunt niks cruciaals wijzigen aangezien je een db gebruiker bent met beperkte rechten en niet de db gebruiker die alles mag. Dus wel degelijk wordt injection tegen gegaan.

eamelink schreef op maandag 04 april 2005 @ 17:29:
Gebruiker website != gebruiker database.
Of wil je soms per hit eerst gaan kijken op welke tables de gebruiker van die pagina wel of niet zou mogen zitten, dan alle table permissies wijzigen, en dan aan het einde van de request weer goedzetten? Dat lijkt me _tamelijk_ inefficiënt.

Als je het zo doet is het inefficient maar waar concludeer jij uit dat "Gebruiker website != gebruiker database."

kijk jij komt nu domweg met pruts voorbeelden en dan is het niet handig om te doen. Maar met dergelijke prutst voorbeelden kun je beter helemaal niet programmeren.

_{Er werd al geprogrammeerd voordat de php prutsers kwamen hoor}

[ Voor 4% gewijzigd door Verwijderd op 04-04-2005 18:17 ]

[jochemd]

Verwijderd schreef op maandag 04 april 2005 @ 15:36:

Hoe zou ik ervoor kunnen zorgen dat de database 'weet' welke gebruiker er bezig is?

Door van elke CMS gebruiker een database gebruiker te maken.

[Verwijderd]

Verwijderd schreef op maandag 04 april 2005 @ 18:13:
[...]
Je kunt niks cruciaals wijzigen aangezien je een db gebruiker bent met beperkte rechten en niet de db gebruiker die alles mag. Dus wel degelijk wordt injection tegen gegaan.

SQL Injection wordt niet tegengegaan, enkel de mogelijk kwalijke effecten worden beperkt.

[BCC]

Houd er wel rekening mee dat dit alleen kan (of het handig is een tweede) als je complete internetsite uit de database gegenereerd wordt. Anders zijn de rechten mogelijkheden in je database niet toereikend en kun je beter een eigen laag gebruiken. Ook moet je er rekening meehouden dat de meeste rechtensystemen in databases geen functionaliteiten als groepen rechten en/of makkelijke grants toestaan (of rechten op rows), wat nogal wat restricties op je ontwerp legt.

[Gomez12]

Verwijderd schreef op maandag 04 april 2005 @ 20:24:
[...]

SQL Injection wordt niet tegengegaan, enkel de mogelijk kwalijke effecten worden beperkt.

Met de nadruk op beperkt en niet tegengegaan, stel je voor een gebruiker mag artikelen toevoegen en verwijderen. Dan kan deze gebruiker nooit de gebruikerstabel leeghalen, want hier heeft hij in de dbase tabel geen rechten voor, maar alle artikelen verwijderen mag hij wel, want hij mag in de table articles deleten. Dus het netto effect is naar mijn mening dat je 2 beveiligingssystemen naast elkaar moet gebruiken omdat er in je applicatie ook wel enige rechtenvalidatie moet zijn.

Alhoewel het idee natuurlijk niet verkeerd is als extra beveiling, maar ik zou het nooit inzetten als primaire beveiling.

[BCC]

Gomez12 schreef op maandag 04 april 2005 @ 20:36:
[...]
hier heeft hij in de dbase tabel geen rechten voor, maar alle artikelen verwijderen mag hij wel, want hij mag in de table articles deleten. Dus het netto effect is naar mijn mening dat je 2 beveiligingssystemen naast elkaar moet gebruiken omdat er in je applicatie ook wel enige rechtenvalidatie moet zijn.

My point exactly. Ik heb nog geen DBMS gezien die row beveiligingen heeft, en dat gebruik je best vaak. Bestanden met eigenaars, Foto's Albums met admin's etc.. Dat soort functies zou je dan via een soort "sudo" functie moeten doen die checked of jij rechten hebt om de geselecteerde row te verwijderen en hem dan verwijdert

[Verwijderd]

BCC schreef op maandag 04 april 2005 @ 20:46:
My point exactly. Ik heb nog geen DBMS gezien die row beveiligingen heeft

Postgresql

[simon]

misschien is het handig ze eerst tegen elkaar aftewegen alvorens een keuze te maken.. 't is imho niet erg fijn voor je portability, zo'n shitload aan users plus rechten enz... Dat het kan is een heel ander verhaal.

[JaQ]

BCC schreef op maandag 04 april 2005 @ 20:46:
[...]
My point exactly. Ik heb nog geen DBMS gezien die row beveiligingen heeft, en dat gebruik je best vaak. Bestanden met eigenaars, Foto's Albums met admin's etc.. Dat soort functies zou je dan via een soort "sudo" functie moeten doen die checked of jij rechten hebt om de geselecteerde row te verwijderen en hem dan verwijdert

dan moet je beter kijken. Oracle heeft het o.a.

Wat je dus wilt is iets wat Oracle "virtual private database" noemt. Lees de technische documentatie maar eens na op http://otn.oracle.com , dan kan je wat ideeën op doen voor hoe je dat kan bereiken. (je hebt overigens vast wel een of andere variable in de postgresql database zitten die je de database username terug geeft, je zou ook met een internal variable kunnen werken)

[raptorix]

BCC schreef op maandag 04 april 2005 @ 20:46:
[...]


My point exactly. Ik heb nog geen DBMS gezien die row beveiligingen heeft.

Dat soort zaken handel je meestal af via een trigger, eventueel kan je nog bepaalde zaken afdwingen door een rule.

[BCC]

raptorix schreef op dinsdag 05 april 2005 @ 10:10:
[...]
Dat soort zaken handel je meestal af via een trigger, eventueel kan je nog bepaalde zaken afdwingen door een rule.

Ok, maar dan komt het portable verhaal weer om de hoek kijken. Het gaat dan zeker niet draaien op MySQL + PHP.

[raptorix]

BCC schreef op woensdag 06 april 2005 @ 10:37:
[...]

Ok, maar dan komt het portable verhaal weer om de hoek kijken. Het gaat dan zeker niet draaien op MySQL + PHP.

Ik snap zowiezo nooit de keuze waarom men zo graag profesionele toepassingen wilt bouwen met deze combinatie, ik zeg niet dat het niet mogelijk is, maar er zijn zoveel andere (gratis/os) oplossingen die veel sterker zijn. Tjah als argument wordt vaak aangedragen dat men ervaring heeft met deze combinatie, maar dat vind ik zelf nogal gemakzucht. Ik heb diverse CMS'en gebouwt, en zeker als het een wat langere levensduur heeft is een sterk database verhaal gruwelijk belangrijk. Als je database al niet dwingt tot een goede structuur kan ik je nu al voorspellen dat het binnen een jaar uit de klauwen loopt.

[Verwijderd]

Verwijderd schreef op maandag 04 april 2005 @ 18:11:
Je kan toch de hele boel opzetten met grants en dan in je pg_connect inloggen als de betreffende gebruiker? Sowieso regelt postgres dan de toegang tot tabellen of views en wat je daarop mag los laten en mocht je het nodig vinden (bv binnen een trigger of stored procedure) te weten welke gebruiker er op dit moment bezig is, bestaan er dacht ik functies binnen posgres die de naam terug geven van de huidige gebruiker... Verder lijkt het me niet nodig om met extra tabellen te werken. Het is gewoon een feature van een "hedendaagse" db...

Nadeel is dat een gebruiker van je CMS ook een user binnen postgres moet zijn, maar verder lijkt me dit niet echt moeilijk... Of ik moet je vraag verkeerd hebben begrepen...

PS: Groeten aan marijn

Juist! Jij begrijpt EXACT waar ik mee bezig ben! Dit is ook hoe het gaat werken nu Volgens mij kennen wij elkaar

Het is inderdaad zo dat bijvoorbeeld een DELETE op een table een trigger oproept. Die trigger gaat dan kijken (op basis van de rechten die je in je CMS instelt en opslaat in dbase tabellen) op de gebruiker (cms en databasegebruiker) gemachtigd zijn. En inderdaad: er is voor iedere CMS gebruiker ook een database gebruiker. Op deze manier kun je je rechten gebruiksvriendelijk instellen (in je CMS webinterface) en de triggers zoeken dit uit in de database. Moet je wel goed regelen dat die users niet de tabellen kunnen aanpassen met rechten erin.

Hiermee stel je de security zo laag mogelijk in: in de database. En ja: ook dit is niet 100% waterdicht. Maar dat is niets...

[ Voor 27% gewijzigd door Verwijderd op 07-04-2005 15:25 ]

[jochemd]

Verwijderd schreef op donderdag 07 april 2005 @ 15:21:

Het is inderdaad zo dat bijvoorbeeld een DELETE op een table een trigger oproept. Die trigger gaat dan kijken (op basis van de rechten die je in je CMS instelt en opslaat in dbase tabellen) op de gebruiker (cms en databasegebruiker) gemachtigd zijn. En inderdaad: er is voor iedere CMS gebruiker ook een database gebruiker.

Maar wat is dan het probleem? Je vraag was hoe de database wist welke user er bezig was. Ligt het antwoord CURRENT_USER dan niet een klein beetje voor de hand?

[Verwijderd]

jochemd schreef op donderdag 07 april 2005 @ 15:47:
[...]

Maar wat is dan het probleem? Je vraag was hoe de database wist welke user er bezig was. Ligt het antwoord CURRENT_USER dan niet een klein beetje voor de hand?

Je zegt het goed: dat ligt EEN KLEIN BEETJE voor de hand

ALLE rechten die in het CMS gelden (ik noem maar wat: deze pagina mag je alleen bewerken, deze mag je activeren, weet ik het allemaal...) in je database user opslaan is niet goed mogelijk.

Wat je nu doet is alle rechten opslaan via je script in database tabellen. Voor iedere CMS user is ook een database user (de naam hiervan is hetzelfde als het CMS user id). Iedere database user heeft dezelfde rechten (klinkt raar misschien) maar die rechten worden ingeperkt door de triggers in de database. Want die bepalen of de CURRENT_USER (daar heb je hem ) een bewerking mag uitvoeren op basis van de informatie in de tabellen.

Het klinkt ingewikkeld, maar is eigenlijk heel logisch.