nicht angemeldet
Hi!
Beide Punkte müssen dann aber auf einer höheren Ebene gesichert werden, denn zumindest MySQL reicht nicht allein das Zugriffrecht auf eine SP, es werden auch noch alle erforderlichen Zugriffsrechte für die darin angesprochenen Elemente benötigt.
Das habe ich anders ermittelt. Es ist möglich, einem User die Zugriffsrechte auf Tabellen zu verbieten und ihm nur die Benutzungsrechte an einer SP zu geben. Diese kann er dann über sein Interface aufrufen. In der SP kann festgelegt werden, dass diese mit den Rechten des Erstellers ausgeführt wird.
Der letzte Satz ist entscheidend. Per Default wird SQL SECURITY DEFINER gesetzt und da reicht tatsächlich das EXECUTE-Privileg. Stellt man das explizit auf SQL SEQURITY INVOKER braucht es auch noch alle notwendigen data-spezifischen Rechte (SELECT-, INSERT-, UPDATE- und/oder DELETE-Privileg). Also ziehe ich meine ursprüngliche Aussage zurück.
- die Datenbank über unterschiedliche APIs/GUIs ansprechen will, also z.B. per HTTPS mit PHP,
direkt im LAN per C++-Frontend, usw.
Wo ist da der direkte Zusammenhang zu Stored Procedures, und was spielt im Speziellen HTTPS für eine Rolle?
Na, ist es denn nicht möglich per HTTPS ein PHP-Script aufzurufen, das dann die Datenbank anspricht? Hast Du vielleicht das 'z.B.' überlesen?
Sicherlich wird es auch über andere Protokolle möglich sein, PHP-Scripte aufzurufen. Die wollte ich hier aber nicht gerne aufzählöen. Und HTTPS steht hier bei mir für ein relativ sicheres Protokoll, das man mit handelsüblichen Browsern nutzen kann.
Ja, aber mir ist nicht klar, was das besondere an HTTPS gegenüber allen anderen Protokollen oder einem protokoll-losen Aufruf von PHP von der Kommanzozeile ist. Du irritierst mich hier mit der expliziten Erwähnung von HTTPS, obwohl das überhaupt keine Rolle spielt. 'PHP' allein hätte jedenfalls nicht impliziert, dass es einen Unterschied zwischen HTTPS und anderen Aufrufvarianten geben könnte.
Lo!