Object access control
Gebruiksrechten
Het is meestal niet de bedoeling dat elke gebruiker van een database alle data kan opvragen, alle stored procedures kan uitvoeren, enzovoort. Iedere gebruiker heeft bepaalde rechten. Denk maar aan een onderneming met een centrale database en veel rollen binnen de onderneming. Beeld je bijvoorbeeld een ziekenhuis in:
de boekhoudkundige dienst moet aan financiële gegevens kunnen, maar niet aan medische gegevens
de artsen moeten aan medische gegevens kunnen, maar niet aan financiële gegevens
de IT-dienst moet de werking van de database zelf kunnen aanpassen
...
Om dit niet aan de verantwoordelijkheidszin van de gebruikers over te laten, creëren we gebruikers met beperkte rechten.
Een gebruiker creëren
We demonstreren dit door een gebruiker 'ap'@'%'
aan te maken. Het percentteken betekent dat het niet uitmaakt of de user op dezelfde machine werkt als die waarop de MySQL-server draait. Als je dat wel wil afdwingen en je werkt op een UNIX-systeem, gebruik je localhost in plaats van %.
Als je de cursus mee hebt gevolgd zoals bedoeld, dus met een virtuele machine waarin je server draait, is localhost geen optie. Je virtuele machine (die inderdaad UNIX-gebaseerd is) wordt niet beschouwd als dezelfde machine als je fysieke machine.
Standaard heeft deze nieuwe gebruiker geen rechten. We verlenen het recht om stored procedures uit te voeren als volgt:
Hier staat de *
voor alle stored procedures. Je kan ook specifieke stored procedures toegankelijk maken. Je kan ook rechten op bepaalde databases, tabellen,... geven. We kunnen hier geen volledige lijst geven, maar de mogelijkheden vind je terug in de officiële documentatie.
Andere manieren om toegang te geven:
Maar wat betekent het om een stored procedure te mogen uitvoeren als je niet alle instructies in die stored procedure mag uitvoeren? Als je bijvoorbeeld DoeBetaling
mag uitvoeren maar niet het recht hebt om een tabel Rekeningen
aan te passen, terwijl DoeBetaling
dat achter de schermen wel doet? Het hangt ervan af. Om daar een antwoord op te geven, moeten we weten of de stored procedure uitvoert als definer (de user die deze stored procedure gedefinieerd heeft) of als invoker (de user die nu de stored procedure wil uitvoeren).
Definer
Syntax:
Als je zelf geen definer invult, is de definer van een stored procedure sowieso de account waarmee de stored procedure is aangemaakt.
Sql Security
Een stored procedure een SECURITY
clausule bevatten met een waarde voor de DEFINER
of de INVOKER
. Dit bepaalt hoe de procedure zich gedraagt wanneer ze wordt uitgevoerd door een user met beperkte rechten.
Syntax:
SQL SECURITY DEFINER
Met de DEFINER
zal de stored procedure in de beveiligingscontext worden uitgevoerd bepaald door het DEFINER
-attribuut.
Hierdoor kan een stored procedure worden uitgevoerd met meer rechten dan de gebruiker zelf heeft.
SQL SECURITY INVOKER
Indien je gebruik maakt van het INVOKER
-attribuut zal het DEFINER
-attribuut geen effect meer hebben.
Voorbeeld
In onderstaande stored procedure hebben we via het DEFINER-object bepaald dat de gebruiker alle rechten heeft die we zelf altijd hebben gebruikt.
Dit wil dus zeggen dat iedere gebruiker, ongeacht zijn security level, deze stored procedure kan uitvoeren met volledige rechten, omdat er SQL SECURITY DEFINER
staat.
Let op! DEFINER
is de defaultwaarde. Als je niet aandachtig bent, kan het dus zijn dat je users meer rechten geeft dan bedoeld.
Vervolgens gaan we met de voorbeeldgebruiker inloggen. Doe dit als volgt.
Kijk even na op welke databases je enige rechten hebt.
Geef vervolgens aan welke db je wilt gebruiken.
Zoals je merkt, uit het schema-venster heb je enkel rechten op de stored procedures.
Om een stored procedure uit te voeren geef je volgende opdracht.
Last updated
Was this helpful?