PostgreSQL und DB-Benutzer

Spezielle Fragen zu PostgreSQL, MySQL, SQLite, SQL ...
Antworten
Benutzeravatar
Honsek
Foriker
Beiträge: 408
Registriert: Do 4. Okt 2007, 17:01
Kontaktdaten:

PostgreSQL und DB-Benutzer

Beitrag von Honsek » Do 17. Okt 2019, 12:10

Hallo,

für das Kapitel zum Thema 'Datenbanken mit Gambas und PostgreSQL' im Gambas-Buch möchte ich nach Möglichkeit nahe an der Praxis sein. Leider fehlen mir da aber Erfahrungen. Ich gehe daher meinen Ideen nach: Ein DB-Administrator betreut einen PostgreSQL-Server:
  • Zuerst legt er eine Datenbank testdb und eine Datenbanktabelle testtable1 an.
  • Dann erzeugt er eine DB-Gruppe testgroup.
  • Danach erblicken drei Datenbank-Benutzer u1, u2 und u3 das Licht des Monitors.
  • Anschließend werden diese Datenbank-Benutzer zur DB-Gruppe testgroup hinzugefügt.
  • Abschließend erteilt er der Gruppe bestimmte Berechtigungen für die Arbeit mit Datenbank-Objekten - hier Datenbanktabelle testtable1 - welche die drei Datenbank-Benutzer u1, u2 und u3 hoffentlich erben.
Wie all das zu realisieren ist, erkunde ich zur Zeit auf der Konsole. Ich bin schwer beeindruckt, was PostgreSQL zu leisten vermag - wenn man das immanente Potential abzurufen vermag.

Liege ich mit meiner oben skizzierten Idee halbwegs richtig?
Wenn JA, dann reicht mir ein kurzer Kommentar - sonst bitte ich um einen größeren Fingerzeig in die richtige Richtung.

Mit freundlichem Gruß

Hans
Zuletzt geändert von Honsek am Fr 18. Okt 2019, 12:22, insgesamt 1-mal geändert.
Honsek (https://www.gambas-buch.de)
---> Wenn Du eine gute Antwort erwartest, musst Du sehr gut fragen!

Benutzeravatar
tionov
Site Admin
Beiträge: 314
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von tionov » Do 17. Okt 2019, 16:02

Hallo Honsek,

Grundsätzlich funktioniert das "tägliche" SQL mit Postgresql [PG] genau so wie mit SQLite.

Mit Postgresql benötigt man nicht unbedingt Gruppen (roles), die Benutzer (ebenfalls roles) enthalten, wenn z.B. eine
Applikation die Rechte selbst verwaltet, wie es allgemein die Regel ist.

In unserem Betrieb z.B. gibt es einen Benutzer auf PG-Seite. Das ist der DB-Benutzer den unsere Applikation verwendet. Von dieser Applikation können ganz viele auf verschiedenen Computern gestartet und mit dem Postgresql Server verbunden sein, ähnlich wie in Linux, in dem du als ein User mehrere Terminals aufmachen kannst. Unsere Applikation verwaltet wiederum ihre eigenen Benutzer und deren Rechte selbst.

Ähnlich arbeitet das OTRS-Ticketsystem, das seine User selbst verwaltet und nur einen einzigen Benutzer "otrs" für die DB "otrs" kennt.

Auf Shared Hosts im Web, wo viele Datenbanken liegen, die vielen Teilnehmern gehören, ist die Regel stets: ein Benutzer => eine Datenbank.

In einem Shopsystem, das auf einem Apache Webserver läuft, der auf eine Datenbank zugreift, ist ebenfalls die Regel: ein DB-Benutzer => eine Datenbank. Obwohl viele verschiedene Menschen zugleich an dem Shopsystem angemeldet sind und gemeinsam an der Datenbank Daten lesen und ändern, greift das Shopsystem mit einem einzigen Benutzernamen und zugehörigem Passwort auf die Datenbank zu. Nur unter Umständen eben mehrfach, mit potentiell vielen Connections.

Also empfehle ich deinen Ansatz, wenn ich genauer darüber nachdenke, nicht. Und so wird es auch im Allgemeinen nicht gemacht.

Ich empfehle: Ein Benutzer => eine Datenbank. Die Kombination aus Benutzername (Username) und Passwort ist quasi der Schlüssel, der den Zugang zur Datenbank ermöglicht.

Was nun PG von SQLite wirklich deutlich unterscheidet, ist das Locking und damit die Multiuser- nein besser Multiconnectionfähigkeit (Concurrency) und das Transaction Handling. Ich bin mir sogar jetzt nicht mal genau sicher, wie der aktuelle technische Stand ist, aber mit Multiuserfähigkeit ist vor allem gemeint, dass PG die Daten davor bewahrt, dass sie von verschiedenen Benutzern (besser: Connections) zeitgleich bearbeitet und dabei zerstört werden können.

Ppstgresql sorgt für Datenintegrität beim Bearbeiten der Daten mit multiplen Connections.

Während SQLite beim Schreiben stets die ganze Datenbank sperrt, beobachtet PG die Tabellen und ihre Zeilen und sperrt nur die Tuples (=Zeilen in einer Tabelle), die gerade beschrieben werden. Damit kommen sich die verschiedenen an der DB arbeitenden Connections in der Regel nicht ins Gehege.

Das Ganze ist hier beschrieben (da siehst du auch gleich wie komplex das Ganze ist, die gute Nachricht dabei ist, dass du dich selbst eigentlich nicht darum kümmern musst, das macht in der Regel PG selbst):

https://www.postgresql.org/docs/9.6/mvcc.html

Viele Connections können damit zugleich in den selben Tabellen lesen und schreiben, in Transactions sogar weitgehende Änderungen über mehrere Tabellen hinweg *atomar* vollziehen (oder auch wieder zurücknehmen) und die Daten bleiben absolut sicher genau so erhalten wie sie übergeben wurden.

Du erinnerst dich, dass ich so darauf bestanden habe, dass in einer Applikation immer nur eine einzige Connection benutzt wird? Der Grund ist das Locking, das Sperren von Datensätzen durch PG, das dann auftritt, wenn zugleich von zwei Stellen auf einen Datensatz zugegriffen wird.

Es kann zu Situationen kommen, in denen von zwei Connections aus in einer ungünstigen Form Datensätze beschrieben werden, sodass die Connections sich gegenseitig sperren. Jede von zwei Connections wartet darauf, dass die jeweils andere mit der Änderung fertig ist. Das ist dann ein Deadlock:

https://www.postgresql.org/docs/9.6/exp ... -DEADLOCKS

Da hält dann die Verarbeitung einfach an. Nicht mal ein Neustart der Applikation hilft, sondern Warten, bis der Server nach einer bestimmten Zeit beide abbricht und danach den Zugriff wieder frei gibt oder ein Neustart des Servers.

Ich habe das früher auch durchaus mit einer einzigen Applikation geschafft, die "versehentlich" (= Dummheit des Programmierers) mit mehreren Connections auf die DB losging.
Alles Gute,

tionov

Benutzeravatar
tionov
Site Admin
Beiträge: 314
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von tionov » Do 17. Okt 2019, 17:05

Hier eine Darstellung möglicher Zugriffe vieler (menschlicher) Benutzer auf eine Datenbank. Die grünen Pfeile sind die Connections, die die Apps zur Datenbank aufgebaut haben und über die sie Daten lesen/schreiben. Beachte: Alle Connections haben die selbe Kombination aus Benutzer/Passwort als Zugangsberechtigung zur Datenbank. Trotzdem kann die Datenbank die einzelnen Connections voneinander unterscheiden.
db-multiple-connections.png
db-multiple-connections.png (88.35 KiB) 116 mal betrachtet
1) Jeder Benutzer hat eine App gestartet und diese ist je mit einer Connection mit der Datenbank verbunden. Das ist z.B. sinnvoll, wenn man mit Gambas einen Datenbank-client schreibt, und dieser auf verschiedenen Computern gestartet wird, um menschlichen Benutzern die Gelegenheit zu geben, über ein Netzwerk auf die DB zuzugreifen.

2) Alle Benutzer sind mit einer App verbunden und diese vermittelt in mehreren Connections den Zugriff zur Datenbank. Das ist typisch für Applikationen, die selbst auf einem Server liegen. Z.B. ein Webshop. Menschliche Benutzer greifen über ein Netzwerk auf die App zu, die den Webshop darstellt. Pro menschlichem Benutzer startet die App eine Connection zur Datenbank.
Alles Gute,

tionov

Benutzeravatar
PJBlack
Foriker
Beiträge: 29
Registriert: Sa 8. Dez 2018, 23:50
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von PJBlack » Do 17. Okt 2019, 19:30

Wäre es aber bei Beispiel 1 nicht sinnvoller die Benutzer auf dem Datenbankserver zu verwalten?

Benutzeravatar
tionov
Site Admin
Beiträge: 314
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von tionov » Do 17. Okt 2019, 20:45

PJBlack hat geschrieben:
Do 17. Okt 2019, 19:30
Wäre es aber bei Beispiel 1 nicht sinnvoller die Benutzer auf dem Datenbankserver zu verwalten?
Jein. ;-)

Es kommt darauf an, was man unter verwalten versteht.

Ich würde in der Regel davon abraten, wenn man sich dabei alleine auf die Rechteverwaltung der DB selbst beschränkt. Man kann Rechte feiner granulieren, wenn sie nicht alleine auf den Zugriff auf Datenbanken, Tabellen und Funktionen der DB beschränkt sind (das sind die Rechte, die Postgresql für "roles" bereithält). Vielleicht hat die App Bereiche, die gar nichts mit der DB zu tun haben, aber durch Rechte geschützt werden sollen? Oder vielleicht kommen solche später dazu?

Üblicherweise findet man in datenbankgestützten Softwares zur Rechteverwaltung Tabellen mit Namen wie "user" und "user_right", in denen Zugangsdaten und Rechte auf irgendeine Weise gespeichert und dann von der App abgefragt werden, wenn sich ein Benutzer "einloggt". Die App kontrolliert dann, ob auf Bereiche der App selbst (und eventuell der DB) zugegriffen werden kann.

Das eine schließt das andere aber nicht aus. Ich finde roles, wie sie in Postgresql vergeben werden können, dann sinnvoll, wenn ich eine Software auf bestimmte Bereiche einer Datenbank beschränken möchte. So können zum Beispiel nächtens ablaufende Service- oder Auswerteskripte beschränkt werden.

Vor allem aber dienen roles dazu, die Hoheitsbereiche verschiedener Softwares, die auf einen Datenbankserver zugreifen, voneinander abzugrenzen. Da läuft dann das Ticketsystem mit der DB "otrs" auf die alleine von der role "otrs" aus zugegriffen wird , das Wiki mit der DB "wiki" und der analogen role "wiki", usw.
Alles Gute,

tionov

Benutzeravatar
PJBlack
Foriker
Beiträge: 29
Registriert: Sa 8. Dez 2018, 23:50
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von PJBlack » Do 17. Okt 2019, 23:49

Ok, ich habe mich missverständlich ausgedrückt. Aber letztlich hast Du mich ja verstanden und danke für die umfangreiche Antwort.

Das Problem was ich mit einem zugreifenden Benutzer habe ist, das dieser vollen Zugriff hat und das Passwort in Gambas irgendwo "rumliegt". Verwalte ich die (Gruppen und) Benutzer innerhalb des DBMS hat jeder Benutzer maximal seine Rechte ...

Oder sehe ich da was falsch?

Benutzeravatar
tionov
Site Admin
Beiträge: 314
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von tionov » Fr 18. Okt 2019, 07:24

PJBlack hat geschrieben:
Do 17. Okt 2019, 23:49
Das Problem was ich mit einem zugreifenden Benutzer habe ist, das dieser vollen Zugriff hat und das Passwort in Gambas irgendwo "rumliegt". Verwalte ich die (Gruppen und) Benutzer innerhalb des DBMS hat jeder Benutzer maximal seine Rechte ...

Oder sehe ich da was falsch?
Nein, das siehst du schon richtig. Das ist ein Schwachpunkt des Ansatzes in 1).

Das Passwort muss natürlich nicht "in Gambas" rumliegen, sondern kann z.B. in einem Formular eingegeben und dann in irgendeiner Weise verschlüsselt in den Settings gespeichert und daraus wieder gelesen werden. Aber selbst dazu muss der Key, um das Passwort zu entschlüsseln wieder "in Gambas" liegen, der dann z.B. als Fehlermeldung getarnt sein kann. Es wird also allenfalls obsfugated.

Es kommt jetzt darauf an in welcher Umgebung wir uns befinden und welche Sicherheit verlangt wird. Da die Gambas Software auch kompiliert als offen betrachtet werden muss, ist also Ansatz 1 inhärent unsicher. Die Frage ist: Wie viel Sicherheit brauche ich diesbezüglich z.B. in einer Büroumgebung? Hackt der Bediener das Passwort indem er den Bytecode von Gambas analysiert und die Funktion rekonstruiert, die das Passwort aufdeckt?

Wenn höhere Sicherheit benötigt wird, sollte man Ansatz 2 wählen oder wirklich eine Rechteverwaltung in der DB selbst etablieren.

Alternativ sind natürlich noch alle möglichen Mischformen denkbar, zum Beispiel eine Kombination beider Ansätze als Schichtenarchitektur.

https://de.wikipedia.org/wiki/Schichtenarchitektur
Alles Gute,

tionov

Benutzeravatar
PJBlack
Foriker
Beiträge: 29
Registriert: Sa 8. Dez 2018, 23:50
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von PJBlack » Fr 18. Okt 2019, 11:05

Danke für die umfangreiche und hervorragend zu lesende Antwort!
tionov hat geschrieben:
Fr 18. Okt 2019, 07:24
Hackt der Bediener das Passwort indem er den Bytecode von Gambas analysiert und die Funktion rekonstruiert, die das Passwort aufdeckt?
Als langjähriger IT'ler sage ich : JA !!! (und er wird dabei, nach Murphys Law, den grösstmöglichen Schaden anrichten)

Benutzeravatar
tionov
Site Admin
Beiträge: 314
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von tionov » Fr 18. Okt 2019, 11:35

Ja, es kommt auf die Umgebung an. Da wo ich arbeite, passiert so was nicht. :-)

Wenn allerdings nur ein Mitarbeiter so wie ich wäre, würde das passieren. Ja.

Ok, dann kann man natürlich in Szenario 1) die Rechteverwaltung der DB nutzen und eventuell dort auch noch zusätzlich Rechte abspeichern, die dann für weitere Bereiche in der App gelten. Dann bekommt jeder Benutzer sein eigenes Passwort für die DB und es können per Roles Gruppenrechte an Datenbank-Objekten vergeben werden. Und – um ganz an den Anfang zurückzukommen, die Frage von Honsek: Dann empfehle ich ihm, es so zu machen, wie er es sich gedacht hat. Für billiges Shared-Hosting ist das dann aber nichts.
Alles Gute,

tionov

Benutzeravatar
Honsek
Foriker
Beiträge: 408
Registriert: Do 4. Okt 2007, 17:01
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von Honsek » Fr 18. Okt 2019, 12:35

Gut.
Jetzt stehe ich wieder am Anfang - bin aber um einige Informationen aus gut formulierten Beiträgen reicher. Es kommt offensichtlich darauf an, in welcher Umgebung gearbeitet wird und wie ein Dienstnutzer (Client) den angebotenen Dienst eines Dienstleisters (Server) sicher nutzt. Daher haben alle oben skizzierten Lösungsansätze ihre Berechtigung. Das werde ich im Buch auch so beschreiben und für den von mir eingangs geschilderten Dienst meine (Gambas-)Lösung anbieten.

Mit freundlichem Gruß

Honsek
Honsek (https://www.gambas-buch.de)
---> Wenn Du eine gute Antwort erwartest, musst Du sehr gut fragen!

Benutzeravatar
tionov
Site Admin
Beiträge: 314
Registriert: So 18. Mai 2014, 22:40
Kontaktdaten:

Re: PostgreSQL und DB-Benutzer

Beitrag von tionov » Sa 19. Okt 2019, 21:03

Ich meine, ich muss etwas korrigieren. Wir sind in der Diskussion in meinen Augen etwas von der Frage im Ursprungsposting abgekommen.

Zu Szenario 1) und dessen "Sicherheitsproblem"

Jetzt habe ich mich noch mal etwas mit dem Berechtigungssystem von PG beschäftigt. Ich selbst verwende es im Allgemeinen nur, um Softwares abzuhalten, in Bereichen lesen und schreiben zu können, die sie nichts angehen. Nicht menschlichen Benutzern.

Enthält die DB z.B. Tabellen für Kunden und Bestellungen und ich möchte, dass ein Benutzer mit der App nur die Kundenadressen lesen und ändern kann, nicht aber die Bestellungen der Kunden dann regele ich das in der App, die auf die DB zugreift. Und zwar darüber, dass ich dem Benutzer in der App ein Recht gebe oder verweigere, das Formular für Kunden anzusehen und das Recht, ein Formular für Bestellungen anzusehen. Die App hat Zugriff auf alle Tabellen.

Wenn aber per Cron in der Nacht automatisch länger dauernde Abfragen an die DB gestellt werden, die nur allein die Tabellen, die Bestellungen enthalten, betreffen, dann verpasse ich dem eigene Zugangdaten, und beschränke damit den Zugriff nur auf die gewünschten Tabellen.

Damit nicht jede Person, die die App starten kann, nun freien Zugriff auf die Datenbank hat, liegen die Zugangsdaten (Credentials) selbstverständlich(!) nicht im Code der App, sondern verschlüsselt in den Settings und werden durch ein Passwort geschützt, das der Benutzer beim Starten der App eingeben muss. Zum Beispiel, es gibt auch viele andere Möglichkeiten, Credentials zu schützen.

Das PG Berechtigungssystem ist mächtig, kompliziert und nicht ohne Tücken, das ist absolut kein Thema für Anfänger:
https://marcyes.com/2016/0922-messing-w ... rmissions/

Und Sicherheit kann beliebig kompliziert und esoterisch abgehandelt werden. Es gibt aber Szenarien, da ist die Sicherheit nur von geringer Wichtigkeit.

Darum meine Empfehlung:

Honseks Originalposting liegt die Frage zugrunde, wie er Möglichkeiten von Postgresql für das Gambas-Buch darstellen soll. Das Rechtesystem von PG ist nicht das herausragende Feature der vielen, die PG bietet. Das wichtigste ist das Concurrency Handling, also dass PG es ermöglicht, dass zugleich viele Benutzer an der Datenbank arbeiten und dort Daten lesen und schreiben können, ohne sich gegenseitig zu behindern. Gleich bedeutend sind für mich Transactions, die mehrere Änderungen zu einer einzigen zusammenfassen, die atomar ausgeführt wird oder eben nicht.

So und genau um dieses darzustellen, dafür empfehle ich, Szenario 1 zu verwenden, und eine kleine App zu bauen, die mit identischen Zugangsdaten auf dem selben Computer mehrfach gestartet werden kann und gegen einen Postgresql Server auf dem selben Computer arbeitet. Da dürfen die Zugangsdaten auch erstmal im Code liegen.

Wie man die Zugangsdaten dann extern in den Settings speichert, wäre dann der nächste Schritt.

Wie man die Zugangsdaten mit einem Passwort ver- und beim Start der App entschlüsseln kann, wäre ein weiterer.
Alles Gute,

tionov

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste