Seite 1 von 1

PostgreSQL "Gruppen" / "Privilegien"

Verfasst: So, 19. Aug 2012 20:07
von AUGE_OHR
hi,

wenn ich nun mehrere Clients habe die auf den PostgreSQL Server zugreifen ...

Frage : wie viele User kann ein PG Server "verwalten" ?

ich "denke" das ich für die User eine "Group" angelegen muss

Code: Alles auswählen

CREATE GROUP name
und dann die einzelnen Namen einfügen muss

Code: Alles auswählen

ALTER GROUP name ADD USER bname1, ... ;
nun benötigt ein User ja "Privilegien" um Aktionen ausführen zu können.

Code: Alles auswählen

GRANT UPDATE ON konten TO joe;
hier hat der User "joe" das Recht für "UPDATE"

wenn nun "joe" in eine "GROUP" ist, könnte man auch der ganzen "GROUP" das Recht geben

Code: Alles auswählen

GRANT SELECT ON konten TO GROUP MeineGroupe;
so weit so gut ...
CREATE GROUP erzeugt eine neue Gruppe im Datenbankcluster.
Um diesen Befehl verwenden zu können, müssen Sie ein Datenbank-Superuser sein.
Frage : was ist "der" Datenbank-Superuser bei einer "default" Installation ? ( postgres ? )

wenn ich den User "joe" angelegt habe ... wie / wo kann der "User" sein Passwort "ändern" ?
oder muss das auch der Datenbank-Superuser mit

Code: Alles auswählen

ALTER USER joe WITH PASSWORD 'hu8jmn3';
machen ?

wenn ich nun
Einem Benutzer die Fähigkeit, andere Benutzer und neue Datenbanken zu erzeugen, gebe:
mit

Code: Alles auswählen

ALTER USER joe CREATEUSER CREATEDB;
ist das dann auch ein Datenbank-Superuser oder nur ein USER mit speziellen Rechten ?

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mo, 20. Aug 2012 6:50
von georg
Guten Morgen, Jimmy -


warum?

Grundsätzlich regelt das Anwendungsprogramm den Zugriff auf den SQL-Server, d.h. es gibt einen Standard-User, dessen Username und Passwort von allen Anwendern "geshared" wird.

Persönlich würde ich keinem Anwender irgendwelche Administrationsrechte auf dem Server einräumen. Ein DROP TABLE ist schnell geschehen. "Ich wollte doch nur wissen, was passiert!"

Solange die Anwender nicht direkt mit der Datenbank kommunizieren (durch Dein Programm ist es immer eine indirekte Kommunikation), ist es kaum erforderlich, dass jeder Anwender ein eigenes Profil hat.

Man kann zwar den Zugriff auf bestimmte Tabellen einschränken, weil die nicht jeder einsehen darf. Dann muss aber das Programm, das mit dem Server arbeitet, auf solche Konstellationen eingerichtet sein: es muss erkennen, dass eine Tabelle nicht zur Verfügung steht und die Verarbeitung entsprechend anhalten.

So etwas regelt man besser durch eine entsprechende Benutzerverwaltung in Deinem Programm.

Oder hast Du an etwas gänzlich anderes gedacht?


Gruss,

Georg

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mo, 20. Aug 2012 10:55
von UliTs
Hallo Jimmy, hallo Georg

also ich habe auch im Data Dictionary (=Datenbank) vom ADS Gruppen und User eingerichtet.
Das hat einige Vorteile:
1) Ich sehe innerhalb der Datenbank immer, wer sich angemeldet hat und zwar auch OHNE xBASE-Programm!
2) Ich kann auf Datenbankebene die Rechte steuern und so z.B. das Feld "Gehalt" nur für die Geschäftsführung und Buchhaltung sichtbar machen. So sind die Daten wesentlich besser geschützt.
3) Der Zugriff über verschiedene Programme, die gegebenfalls auch mit unterschiedlichen Programmiersprachen geschrieben wurden, ist wesentlich einfacher.

Uli

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mo, 20. Aug 2012 11:16
von georg
Guten (noch) Morgen, Uli -


diese Überlegung kenne ich bereits von der AS/400, wo man über sogenannte logische Dateien (Views, die aber direkten Zugriff auf die Daten erlauben) eine Benutzerberechtigung bis hinunter auf die Feldebene realisieren.

Wenn ich das über die Datenbank regele, ist der Aufwand im Programm recht hoch, da ja der gleiche Code für den Auszubildenden wie für den Geschäftsführer verwendet wird.

Hat der Auszubildende keinen Zugriff auf das Feld GEHALT, so muss das Programm "wissen", dass es solche Konstellationen gibt und diese im Programm-Code abfangen: ich muss also prüfen, welche Felder ich erhalte und darauf reagieren.

Habe ich eine Benutzersteuerung in meinem Programm, über die Berechtigungen abgefragt und umgesetzt werden, so erscheint das Feld GEHALT beim Auszubildenden nicht am Bildschirm.

Für mich persönlich erscheint der zweite Ansatz einfacher, weil ich beim ersten Ansatz theoretisch bei jedem Feld hinterfragen muss, ob es verfügbar ist oder nicht.

Aber nochmals: dies ist eine persönliche Einschätzung.


Grundsätzlich gilt aber: wenn Benutzer direkten Zugriff auf den Server haben und mittels Report-Mechanismen auf die Tabellen (und sei es lesend) zugreifen können, ist der Ansatz mit Benutzer-gesteuerten Berechtigungen sinnvoll, erzeugt aber auch einen recht hohen Verwaltungsaufwand.

Bei uns hat die Personalabteilung quasi ihre eigene EDV, über welche die Gehaltsbuchhaltung gefahren wird, da ist die Gefahr nicht so hoch, dass der Falsche die richtigen Zahlen sieht (oder umgekehrt).


Gruss,

Georg

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mo, 20. Aug 2012 11:28
von UliTs
Hallo Georg,

du hast sicher Recht, das es bei der Verfahrensweise auch Nachteile gibt.
Perfekt ist sicher die Vorgehensweise, dass das Programm grundsätzlich intelligent auf fehlende Tabellen, Felder, Zugriffsrechte etc. reagieren kann.

Da aber auch eine teilweise Realisierung problemlos möglich ist, wenn der Programmierer den Aufbau der Datenbank vollständig kennt, finde ich, das die Vorteile überwiegen.

Uli

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mi, 22. Aug 2012 0:55
von AUGE_OHR
georg hat geschrieben:Ein DROP TABLE ist schnell geschehen. "Ich wollte doch nur wissen, was passiert!"
also zumindest 1 User "muss" ich wohl anlegen den auf dem default User "postgres" darf ich eine normale Applikation wohl nicht laufen lassen ;)

die von euch angesprochenen Themen, mit ihren Vor- / Nach- Teilen sind mir für Xbase ( alle Versionen ) bewusst.
ich denke das diese Überlegungen schon in die Konzept Phase gehören und das "mögliche" abdecken.

dazu gehört nun leider das manchmal der User etwas macht was "so" nicht geplant war ... und die Suche geht los.
klar will es keiner gewesen sein ... also geht man nun die Logfiles durch.

mit Novell Logfiles und mit Windows Logfiles und dem "eigenen" Logfile der Application kommt man dann der Sache auf die Spur.
beim PostgreSQL Logfile habe ich noch Schwierigkeiten dieses mit meinen "eigenen" Logfile zu synchronisieren wenn ich von 2 Workstationen auf den Server zugreife.

ich möchte also das der PostgreSQL Server mir "mehr" Informationen liefert "wann","wer","was" gemacht hat.

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mi, 22. Aug 2012 21:10
von brandelh
Der User der nicht zugibt etwas falsch gemacht zu haben, kann unter Windows nur daher kommen,
dass der Anwender per Explorer oder Fremsoftware auf die per LAN Freigabe verfügbaren Daten zugreift.

Das dürfte es auf dem PostGreSQL (oder einem anderen SQL Server) nicht geben,
weil KEINER einen Zugriff auf dessen physikalisches Datenlaufwerk erhalten darf (außer dem Server natürlich).

Alle anderen "Mißbräuche" muss man in beiden Scenarien im Anwendungsprogramm per Zugriffsberechtigung regeln.
Ich habe normalerweise einen USER für normale Userabfragen und einen für Adminabfragen (mehr Rechte).
Letzterer legt z.B. neue Tabellen an nachdem das Programm installiert wurde ähnlich wie es phpBB macht nach der Installation.

Bei Sicherheitskritischen Anwendungen (Banken etc.) gibt es sicherlich die Vorgabe zusätzlich noch andere Usergruppen festzulegen z.B. Programmfehler abzusichern, aber solches brauche ich nicht. Ich melde meine User am Programm über den USERNAME von Windows, über citrix kann das der Anwender auch nicht mit SET ... ändern.

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Mi, 22. Aug 2012 22:59
von AUGE_OHR
hi,

ich versuche es noch mal andersrum : gibt es bei SQL Server durch "Gruppen" / "Privilegien" Unterschiede zu Novell "Gruppen" / "Privilegien" oder Windows "Gruppen" / "Privilegien" ?

es ist ja nicht so das man vorher nicht mit "Gruppen" / "Privilegien" gearbeitet hat nur evtl mit einem anderen "Konzept".
Wenn also PostgreSQL & Co noch "Extras" haben wo man mit Xbase++ erst lange überlegen muss dann raus damit.

unter PostgreSQL lege ich eine Table im "Catalog" an welches eine "interne" Table ist.
hier sollte ein User wohl "Leserechte" haben.

Code: Alles auswählen

::oR_Table := oPG:Select( "pg_tables",, "schemaname = 'public'" )

METHOD PGSql:Select( cTable, cField, cWhere, cOrder, cLimit, cOffset )      // Edgar
LOCAL cSql

   DEFAULT cField TO "*"
   DEFAULT cWhere TO ""
   DEFAULT cOrder TO ""
   DEFAULT cLimit TO ""                                     // Jimmy
   DEFAULT cOffset TO ""                                    // Jimmy

   cSql := "SELECT " + cField + " FROM " + cTable
   IF !EMPTY( cWhere )
      cSql := cSql + " WHERE " + cWhere
   ENDIF
   IF !EMPTY( cOrder )
      cSql := cSql + " ORDER BY " + cOrder
   ENDIF

   IF !EMPTY( cLimit )                                      // Jimmy
      cSql := cSql + " LIMIT " + cLimit
   ENDIF
   IF !EMPTY( cOffset )                                     // Jimmy
      cSql := cSql + " OFFSET " + cOffset
   ENDIF

   ::exec( cSql )


vs. 

   ::cQuery := "SELECT table_name FROM information_schema.tables " + ;
                     "WHERE table_schema = 'public'"

   IF ::oPG:Exec( ::cQuery )
       ::oR_Table := ::oPG:result
obwohl ich ähnliche Ergebnisse bekomme unterscheidet sich "pg_tables" erheblich von "information_schema.tables" was die "Rechte" angeht.

gibt es sonstige "Extras" bei SQL Server wo sich durch "Gruppen" / "Privilegien" Sachen erledigen kann wo man unter Xbase++ erst lange überlegen muss ?

Re: PostgreSQL "Gruppen" / "Privilegien"

Verfasst: Do, 23. Aug 2012 19:46
von AUGE_OHR