Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PostgreSQL: Passwortabfrage
36 views
Skip to first unread message
Volker Englisch
Oct 23, 2012, 12:26:03 PM10/23/12
to
Ich versuche mich gerade von MySQL kommend, in PostgreSQL
einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
Was mich noch sehr wundert: Gebe ich beispielsweise
$ psql -U irgendwer MEINEDB
ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
Benutzers habe ich sich "... with password('mypassword') angegeben.
Wo habe ich da einen (Denk-)Fehler?
Und - hat jemand einen guten Tipp für einen "Umsteiger", welche Lektüre
sich anzuschaffen lohnt?
TIA
V*
einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
Was mich noch sehr wundert: Gebe ich beispielsweise
$ psql -U irgendwer MEINEDB
ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
Benutzers habe ich sich "... with password('mypassword') angegeben.
Wo habe ich da einen (Denk-)Fehler?
Und - hat jemand einen guten Tipp für einen "Umsteiger", welche Lektüre
sich anzuschaffen lohnt?
TIA
V*
Florian Weimer
Oct 23, 2012, 1:59:13 PM10/23/12
to
* Volker Englisch:
> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
> einzuarbeiten. Ich bin auch schon ein ganzes St�ckchen weit gekommen.
historische Voreinstellungen. --auth=peer stellt das ab.
> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
> Was mich noch sehr wundert: Gebe ich beispielsweise
>
> $ psql -U irgendwer MEINEDB
>
> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
> Benutzers habe ich sich "... with password('mypassword') angegeben.
Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>
> $ psql -U irgendwer MEINEDB
>
> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
> Benutzers habe ich sich "... with password('mypassword') angegeben.
historische Voreinstellungen. --auth=peer stellt das ab.
Marc Santhoff
Oct 23, 2012, 2:12:41 PM10/23/12
to
Am Tue, 23 Oct 2012 16:26:03 +0000 (UTC)
schrieb v.englis...@rsli.de (Volker Englisch):
> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
> einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
Die jeweilige Version passend zu der vorhandenen Installation. Sollte
eigentlich reichen, da ist auch ein Kapitel "Tutorial" und hier
vielleicht "Sever Administraion" - natürlich in englischer Sprache.
Marc
schrieb v.englis...@rsli.de (Volker Englisch):
> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
> einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
> Und - hat jemand einen guten Tipp für einen "Umsteiger", welche
> Lektüre sich anzuschaffen lohnt?
http://www.postgresql.org/docs/
> Lektüre sich anzuschaffen lohnt?
Die jeweilige Version passend zu der vorhandenen Installation. Sollte
eigentlich reichen, da ist auch ein Kapitel "Tutorial" und hier
vielleicht "Sever Administraion" - natürlich in englischer Sprache.
Marc
Volker Englisch
Oct 23, 2012, 4:25:09 PM10/23/12
to
"password" gemacht, jetzt reagiert PostgreSQL so wie erwartet ;-) Und
ich hab was dazu gelernt... Danke!
V*
Volker Englisch
Oct 23, 2012, 4:28:05 PM10/23/12
to
Marc Santhoff <m.san...@t-online.de> wrote:
> Am Tue, 23 Oct 2012 16:26:03 +0000 (UTC)
> schrieb v.englis...@rsli.de (Volker Englisch):
>
>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>> einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
>
>> Und - hat jemand einen guten Tipp für einen "Umsteiger", welche
>> Lektüre sich anzuschaffen lohnt?
>
> http://www.postgresql.org/docs/
> Am Tue, 23 Oct 2012 16:26:03 +0000 (UTC)
> schrieb v.englis...@rsli.de (Volker Englisch):
>
>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>> einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
>
>> Und - hat jemand einen guten Tipp für einen "Umsteiger", welche
>> Lektüre sich anzuschaffen lohnt?
>
> http://www.postgresql.org/docs/
> vielleicht "Sever Administraion" - natürlich in englischer Sprache.
Ja, danke. Ich hatte gehofft, daß es da auch was deutsches gibt, gerne
auch in Form toter Bäume. Naja, muß ich mich halt trotz meines Namens -
oder gerade deswegen - durch die englische Doku kämpfen.
Falls noch jemandem etwas wie "PostgreSQL für Dummies", "PostgreSQL für
Umsteiger von MySQL" oder sowas auf deutsch einfällt - gerne her damit.
V*
Marc Santhoff
Oct 23, 2012, 5:45:24 PM10/23/12
to
Am Tue, 23 Oct 2012 20:28:05 +0000 (UTC)
schrieb v.englis...@rsli.de (Volker Englisch):
> Falls noch jemandem etwas wie "PostgreSQL für Dummies", "PostgreSQL
> für Umsteiger von MySQL" oder sowas auf deutsch einfällt - gerne her
> damit.
Mit den Titeln würde ich mal beim Online-Buchhändler deines geringsten
Mißtrauens die Suchmaschine füttern ... ;)
Marc
schrieb v.englis...@rsli.de (Volker Englisch):
> Falls noch jemandem etwas wie "PostgreSQL für Dummies", "PostgreSQL
> für Umsteiger von MySQL" oder sowas auf deutsch einfällt - gerne her
> damit.
Mißtrauens die Suchmaschine füttern ... ;)
Marc
Andreas Scherbaum
Oct 23, 2012, 7:16:38 PM10/23/12
to
Florian Weimer <f...@deneb.enyo.de> wrote:
> * Volker Englisch:
>
>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>> einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
> * Volker Englisch:
>
>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>> Was mich noch sehr wundert: Gebe ich beispielsweise
>>
>> $ psql -U irgendwer MEINEDB
>>
>> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
>> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
>> Benutzers habe ich sich "... with password('mypassword') angegeben.
>
> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
> historische Voreinstellungen. --auth=peer stellt das ab.
Liegt im Regelfall eher daran was deine Distribution da einstellt.
>>
>> $ psql -U irgendwer MEINEDB
>>
>> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
>> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
>> Benutzers habe ich sich "... with password('mypassword') angegeben.
>
> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
> historische Voreinstellungen. --auth=peer stellt das ab.
Normalerweise darf da auch nur der Unix Benutzer (Windows lassen wir
mal hier außen vor) ohne Passwort zugreifen der auch die Datenbank
betreibt. Also kein großes Risiko.
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Message has been deleted
Volker Englisch
Oct 24, 2012, 6:21:29 AM10/24/12
to
Am 23.10.12 schrieb Marc Santhoff:
>> Falls noch jemandem etwas wie "PostgreSQL f�r Dummies", "PostgreSQL
>> f�r Umsteiger von MySQL" oder sowas auf deutsch einf�llt - gerne her
>> damit.
>
> Mit den Titeln w�rde ich mal beim Online-Buchh�ndler deines geringsten
> Mi�trauens die Suchmaschine f�ttern ... ;)
Done. Danke! ;-)
>> Falls noch jemandem etwas wie "PostgreSQL f�r Dummies", "PostgreSQL
>> f�r Umsteiger von MySQL" oder sowas auf deutsch einf�llt - gerne her
>> damit.
>
> Mit den Titeln w�rde ich mal beim Online-Buchh�ndler deines geringsten
> Mi�trauens die Suchmaschine f�ttern ... ;)
Done. Danke! ;-)
Volker Englisch
Oct 24, 2012, 6:22:58 AM10/24/12
to
Am 24.10.12 schrieb Oliver Sch@d:
> Volker Englisch wrote:
>
>> Und - hat jemand einen guten Tipp f�r einen "Umsteiger", welche
>> Lekt�re sich anzuschaffen lohnt?
>
> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
Die war schonmal gar nicht so schlecht, danke. Jetzt mu� ich erst mal
das Datums-Handling in postgreSQL verinnerlichen (nix mit DATE_FORMAT
und so), dann habe ich denke ich erst mal das Wichtigste kapiert ;-)
V*
> Volker Englisch wrote:
>
>> Und - hat jemand einen guten Tipp f�r einen "Umsteiger", welche
>> Lekt�re sich anzuschaffen lohnt?
>
> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
Die war schonmal gar nicht so schlecht, danke. Jetzt mu� ich erst mal
das Datums-Handling in postgreSQL verinnerlichen (nix mit DATE_FORMAT
und so), dann habe ich denke ich erst mal das Wichtigste kapiert ;-)
V*
Volker Englisch
Oct 24, 2012, 6:21:01 AM10/24/12
to
Am 23.10.12 schrieb Andreas Scherbaum:
> betreibt. Also kein gro�es Risiko.
Bei mir war es so, da� man sich mit jedem beliebigen User auf dem
localhost mit psql anmelden konnte (FreeBSD). W�re es nur der
Datenbank-Owner, w�re ich zufrieden gewesen ;-)
V*
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> * Volker Englisch:
>>
>>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>>> einzuarbeiten. Ich bin auch schon ein ganzes St�ckchen weit gekommen.
>> * Volker Englisch:
>>
>>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>>> Was mich noch sehr wundert: Gebe ich beispielsweise
>>>
>>> $ psql -U irgendwer MEINEDB
>>>
>>> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
>>> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
>>> Benutzers habe ich sich "... with password('mypassword') angegeben.
>>
>> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>> historische Voreinstellungen. --auth=peer stellt das ab.
>
> Liegt im Regelfall eher daran was deine Distribution da einstellt.
> Normalerweise darf da auch nur der Unix Benutzer (Windows lassen wir
> mal hier au�en vor) ohne Passwort zugreifen der auch die Datenbank
>>>
>>> $ psql -U irgendwer MEINEDB
>>>
>>> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
>>> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
>>> Benutzers habe ich sich "... with password('mypassword') angegeben.
>>
>> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>> historische Voreinstellungen. --auth=peer stellt das ab.
>
> Liegt im Regelfall eher daran was deine Distribution da einstellt.
> Normalerweise darf da auch nur der Unix Benutzer (Windows lassen wir
> betreibt. Also kein gro�es Risiko.
Bei mir war es so, da� man sich mit jedem beliebigen User auf dem
localhost mit psql anmelden konnte (FreeBSD). W�re es nur der
Datenbank-Owner, w�re ich zufrieden gewesen ;-)
V*
Siegfried Schmidt
Oct 24, 2012, 7:42:26 AM10/24/12
to
Volker Englisch schrieb:
> Die war schonmal gar nicht so schlecht, danke. Jetzt muￜ ich erst mal
http://www.postgresql.org/docs/9.2/interactive/functions-formatting.html
Siegfried
> Die war schonmal gar nicht so schlecht, danke. Jetzt muￜ ich erst mal
> das Datums-Handling in postgreSQL verinnerlichen (nix mit DATE_FORMAT
> und so)
Es gibt alles was du brauchst, nur der Formatstring sieht etwas anders aus:
> und so)
http://www.postgresql.org/docs/9.2/interactive/functions-formatting.html
Siegfried
Stefan Froehlich
Oct 24, 2012, 10:29:00 AM10/24/12
to
On Wed, 24 Oct 2012 02:21:49 Oliver Sch@d wrote:
> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
> Es gibt da noch mehr vergleichende Webseiten, mit denen man aus der
> MySQL-Welt kommend sehr schnell das Äquivalent in PostgreSQL findet.
In MySQL kann ich ueber mysql.db.*_priv die Zugriffsrechte fuer eine
komplette Datenbank setzen, auch fuer Tabellen, die erst in der Zukunft
angelegt werden.
In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all tables"
gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen hinzu, muss
ich die Zugriffsrechte noch einmal explizit setzen, was im Fall mehrerer
Datenbanken durchaus laestig sein kann.
Habe ich da etwas uebersehen?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Eine Symphonie der Schönheit - Stefan: studieren, welch gares Sehnen!
(Sloganizer)
> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
> Es gibt da noch mehr vergleichende Webseiten, mit denen man aus der
> MySQL-Welt kommend sehr schnell das Äquivalent in PostgreSQL findet.
In MySQL kann ich ueber mysql.db.*_priv die Zugriffsrechte fuer eine
komplette Datenbank setzen, auch fuer Tabellen, die erst in der Zukunft
angelegt werden.
In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all tables"
gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen hinzu, muss
ich die Zugriffsrechte noch einmal explizit setzen, was im Fall mehrerer
Datenbanken durchaus laestig sein kann.
Habe ich da etwas uebersehen?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Eine Symphonie der Schönheit - Stefan: studieren, welch gares Sehnen!
(Sloganizer)
Marc Santhoff
Oct 24, 2012, 1:23:10 PM10/24/12
to
Am 24 Oct 2012 14:29:00 GMT
schrieb Stefan...@Froehlich.Priv.at (Stefan Froehlich):
> In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all
> tables" gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen
> hinzu, muss ich die Zugriffsrechte noch einmal explizit setzen, was
> im Fall mehrerer Datenbanken durchaus laestig sein kann.
>
> Habe ich da etwas uebersehen?
Ich weiß nicht, ob es von PostgreSQL oder eine Systemtool ist, aber
unter FreeBSD gibt es "createdb", siehe manpage.
$ createdb -h localhost -O Stefan NeueDB
tut genau das mit User "Stefan" als Besitzer (großes Oh für "owner" ).
HTH,
Marc
schrieb Stefan...@Froehlich.Priv.at (Stefan Froehlich):
> In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all
> tables" gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen
> hinzu, muss ich die Zugriffsrechte noch einmal explizit setzen, was
> im Fall mehrerer Datenbanken durchaus laestig sein kann.
>
> Habe ich da etwas uebersehen?
unter FreeBSD gibt es "createdb", siehe manpage.
$ createdb -h localhost -O Stefan NeueDB
tut genau das mit User "Stefan" als Besitzer (großes Oh für "owner" ).
HTH,
Marc
Volker Englisch
Oct 24, 2012, 4:12:05 PM10/24/12
to
Am 24.10.12 schrieb Siegfried Schmidt:
> Volker Englisch schrieb:
>
>> Die war schonmal gar nicht so schlecht, danke. Jetzt mu� ich erst mal
to_char(Datumsfeld, 'DD.MM.YYYY') gel�st. Funktioniert wie erwartet und
ist hoffentlich 'State Of The Art' ;-)
V*
> Volker Englisch schrieb:
>
>> Die war schonmal gar nicht so schlecht, danke. Jetzt mu� ich erst mal
>> das Datums-Handling in postgreSQL verinnerlichen (nix mit DATE_FORMAT
>> und so)
>
> Es gibt alles was du brauchst, nur der Formatstring sieht etwas anders aus:
Ich habe es nach Studium der verschiedenen Sites mit
>> und so)
>
> Es gibt alles was du brauchst, nur der Formatstring sieht etwas anders aus:
to_char(Datumsfeld, 'DD.MM.YYYY') gel�st. Funktioniert wie erwartet und
ist hoffentlich 'State Of The Art' ;-)
V*
Volker Englisch
Oct 24, 2012, 4:14:26 PM10/24/12
to
Am 24.10.12 schrieb Stefan Froehlich:
V*
> On Wed, 24 Oct 2012 02:21:49 Oliver Sch@d wrote:
>> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
>
>> Es gibt da noch mehr vergleichende Webseiten, mit denen man aus der
>> MySQL-Welt kommend sehr schnell das �quivalent in PostgreSQL findet.
>> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
>
>> Es gibt da noch mehr vergleichende Webseiten, mit denen man aus der
>
> In MySQL kann ich ueber mysql.db.*_priv die Zugriffsrechte fuer eine
> komplette Datenbank setzen, auch fuer Tabellen, die erst in der Zukunft
> angelegt werden.
JFTR: Ich machte das bisher �ber GRANT ... ON $datenbank.* to $user.
> In MySQL kann ich ueber mysql.db.*_priv die Zugriffsrechte fuer eine
> komplette Datenbank setzen, auch fuer Tabellen, die erst in der Zukunft
> angelegt werden.
V*
Volker Englisch
Oct 24, 2012, 4:20:39 PM10/24/12
to
Am 24.10.12 schrieb Marc Santhoff:
Hmm, ja, createdb habe ich hier auch, ebenfalls FreeBSD. Aber damit ist
"Stefan" der Owner der Datenbank. Was aber, wenn ein weiterer User die
GRANTs erhalten soll, sobald eine neue _Tabelle_ innerhalb der DB
eingerichtet wird?
Z.B. die existierende Datenbank MeineDB. Der User "www" hat �ber GRANT
das SELECT-Recht auf die ganze DB. Nun erstelle ich eine neue Tabelle
(CREATE TABLE NeueTabelle (NR serial, Text text)). Nun hat der User
"www" aber erst (SELECT-) Rechte auf die Tabelle, wenn sie nach
Erstellung explizit vergeben werden. Oder nicht...?
V*
> Am 24 Oct 2012 14:29:00 GMT
> schrieb Stefan...@Froehlich.Priv.at (Stefan Froehlich):
>
>> In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all
>> tables" gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen
>> hinzu, muss ich die Zugriffsrechte noch einmal explizit setzen, was
>> im Fall mehrerer Datenbanken durchaus laestig sein kann.
>>
>> Habe ich da etwas uebersehen?
>
> Ich wei� nicht, ob es von PostgreSQL oder eine Systemtool ist, aber
> schrieb Stefan...@Froehlich.Priv.at (Stefan Froehlich):
>
>> In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all
>> tables" gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen
>> hinzu, muss ich die Zugriffsrechte noch einmal explizit setzen, was
>> im Fall mehrerer Datenbanken durchaus laestig sein kann.
>>
>> Habe ich da etwas uebersehen?
>
> unter FreeBSD gibt es "createdb", siehe manpage.
>
> $ createdb -h localhost -O Stefan NeueDB
>
> tut genau das mit User "Stefan" als Besitzer (gro�es Oh f�r "owner" ).
>
> $ createdb -h localhost -O Stefan NeueDB
>
Hmm, ja, createdb habe ich hier auch, ebenfalls FreeBSD. Aber damit ist
"Stefan" der Owner der Datenbank. Was aber, wenn ein weiterer User die
GRANTs erhalten soll, sobald eine neue _Tabelle_ innerhalb der DB
eingerichtet wird?
Z.B. die existierende Datenbank MeineDB. Der User "www" hat �ber GRANT
das SELECT-Recht auf die ganze DB. Nun erstelle ich eine neue Tabelle
(CREATE TABLE NeueTabelle (NR serial, Text text)). Nun hat der User
"www" aber erst (SELECT-) Rechte auf die Tabelle, wenn sie nach
Erstellung explizit vergeben werden. Oder nicht...?
V*
Siegfried Schmidt
Oct 24, 2012, 4:33:36 PM10/24/12
to
Marc Santhoff schrieb:
> tut genau das mit User "Stefan" als Besitzer (groï¿œes Oh fï¿œr "owner" ).
Der Besitzer eines neu angelegten Objekts in dieser DB ist aber trotzdem
der Anleger des Objektes, nicht der Besitzer der DB.
In PG kann man mit Rollen auf der Datenbankebene Laufzeitparameter
festlegen, aber keine Privilegien an neu erstellte Objekte automatisch
zuweisen.
Siegfried
> tut genau das mit User "Stefan" als Besitzer (groï¿œes Oh fï¿œr "owner" ).
Der Besitzer eines neu angelegten Objekts in dieser DB ist aber trotzdem
der Anleger des Objektes, nicht der Besitzer der DB.
In PG kann man mit Rollen auf der Datenbankebene Laufzeitparameter
festlegen, aber keine Privilegien an neu erstellte Objekte automatisch
zuweisen.
Siegfried
Siegfried Schmidt
Oct 24, 2012, 5:21:33 PM10/24/12
to
Volker Englisch schrieb:
> Ich habe es nach Studium der verschiedenen Sites mit
> to_char(Datumsfeld, 'DD.MM.YYYY') gelöst. Funktioniert wie erwartet
Wenn du ein Datum in dem Stil auch eingeben willst, muss eine passende
Locale oder ein 'set datestyle to german;' bzw. das Äquivalent in der
postgresql.conf gesetzt werden. Dann muss auch an der Ausgabe nichts
formatiert werden.
Siegfried
> Ich habe es nach Studium der verschiedenen Sites mit
> und ist hoffentlich 'State Of The Art' ;-)
Damit gehts am flexibelsten, beeinflusst aber nur die Ausgabe.
Wenn du ein Datum in dem Stil auch eingeben willst, muss eine passende
Locale oder ein 'set datestyle to german;' bzw. das Äquivalent in der
postgresql.conf gesetzt werden. Dann muss auch an der Ausgabe nichts
formatiert werden.
Siegfried
Marc Santhoff
Oct 24, 2012, 5:48:50 PM10/24/12
to
Am Wed, 24 Oct 2012 22:20:39 +0200
schrieb Volker Englisch <v.englis...@rsli.de>:
> Hmm, ja, createdb habe ich hier auch, ebenfalls FreeBSD. Aber damit
> ist "Stefan" der Owner der Datenbank. Was aber, wenn ein weiterer
> User die GRANTs erhalten soll, sobald eine neue _Tabelle_ innerhalb
> der DB eingerichtet wird?
>
> Z.B. die existierende Datenbank MeineDB. Der User "www" hat über GRANT
auch nur ein, irgendeine Automatisierung zu schreiben.
Vielleicht ein Trigger, der bei jedem "create table" ein Skript
in der DB anwirft. Das Skript bekommt den Tabllennamen übergeben und
irgendwie vermittelt, welche User welche Rechte besitzen sollen -
Beispielsweise ein User-Rechte-Tabelle. Oder auch nur als Parameter,
wenn es sich um einen Webserver aka User "www" handelt.
Oder eben ein Skript (sh, python, ...), aus dem gleich nach dem "create
table ..." noch ein "grant ... to www" hinterhergeschickt wird.
So würd' ichs veruchen, vielleicht kennt sich jemand besser mit Details
der Userverwaltung aus und kann weitere, ggf. einfachere Vorschläge
machen.
Marc
schrieb Volker Englisch <v.englis...@rsli.de>:
> Hmm, ja, createdb habe ich hier auch, ebenfalls FreeBSD. Aber damit
> ist "Stefan" der Owner der Datenbank. Was aber, wenn ein weiterer
> User die GRANTs erhalten soll, sobald eine neue _Tabelle_ innerhalb
> der DB eingerichtet wird?
>
> das SELECT-Recht auf die ganze DB. Nun erstelle ich eine neue Tabelle
> (CREATE TABLE NeueTabelle (NR serial, Text text)). Nun hat der User
> "www" aber erst (SELECT-) Rechte auf die Tabelle, wenn sie nach
> Erstellung explizit vergeben werden. Oder nicht...?
Du hast recht, siehe auch Posting von Siegfried. Als Lösung fällt mir
> (CREATE TABLE NeueTabelle (NR serial, Text text)). Nun hat der User
> "www" aber erst (SELECT-) Rechte auf die Tabelle, wenn sie nach
> Erstellung explizit vergeben werden. Oder nicht...?
auch nur ein, irgendeine Automatisierung zu schreiben.
Vielleicht ein Trigger, der bei jedem "create table" ein Skript
in der DB anwirft. Das Skript bekommt den Tabllennamen übergeben und
irgendwie vermittelt, welche User welche Rechte besitzen sollen -
Beispielsweise ein User-Rechte-Tabelle. Oder auch nur als Parameter,
wenn es sich um einen Webserver aka User "www" handelt.
Oder eben ein Skript (sh, python, ...), aus dem gleich nach dem "create
table ..." noch ein "grant ... to www" hinterhergeschickt wird.
So würd' ichs veruchen, vielleicht kennt sich jemand besser mit Details
der Userverwaltung aus und kann weitere, ggf. einfachere Vorschläge
machen.
Marc
Andreas Scherbaum
Oct 24, 2012, 6:03:34 PM10/24/12
to
Volker Englisch <v.englis...@rsli.de> wrote:
> Am 23.10.12 schrieb Andreas Scherbaum:
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>> * Volker Englisch:
>>>
>>>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>>>> einzuarbeiten. Ich bin auch schon ein ganzes Stückchen weit gekommen.
> Am 23.10.12 schrieb Andreas Scherbaum:
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>> * Volker Englisch:
>>>
>>>> Ich versuche mich gerade von MySQL kommend, in PostgreSQL
>>>> Was mich noch sehr wundert: Gebe ich beispielsweise
>>>>
>>>> $ psql -U irgendwer MEINEDB
>>>>
>>>> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
>>>> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
>>>> Benutzers habe ich sich "... with password('mypassword') angegeben.
>>>
>>> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>>> historische Voreinstellungen. --auth=peer stellt das ab.
>>
>> Liegt im Regelfall eher daran was deine Distribution da einstellt.
>> Normalerweise darf da auch nur der Unix Benutzer (Windows lassen wir
>> mal hier außen vor) ohne Passwort zugreifen der auch die Datenbank
>>>>
>>>> $ psql -U irgendwer MEINEDB
>>>>
>>>> ein, werde ich nicht nach dem Passwort gefragt sondern einfach als der
>>>> angegebene Benutzer auf die Datenbank losgelassen. Beim Anlegen des
>>>> Benutzers habe ich sich "... with password('mypassword') angegeben.
>>>
>>> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>>> historische Voreinstellungen. --auth=peer stellt das ab.
>>
>> Liegt im Regelfall eher daran was deine Distribution da einstellt.
>> Normalerweise darf da auch nur der Unix Benutzer (Windows lassen wir
>> betreibt. Also kein großes Risiko.
>
> Bei mir war es so, daß man sich mit jedem beliebigen User auf dem
> localhost mit psql anmelden konnte (FreeBSD). Wäre es nur der
> Datenbank-Owner, wäre ich zufrieden gewesen ;-)
Und wer hat die pg_hba.conf so generiert? PostgreSQL, oder FreeBSD?
Andreas Scherbaum
Oct 24, 2012, 6:06:02 PM10/24/12
to
Stefan Froehlich <Stefan...@froehlich.priv.at> wrote:
> On Wed, 24 Oct 2012 02:21:49 Oliver Sch@d wrote:
>> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
>
>> Es gibt da noch mehr vergleichende Webseiten, mit denen man aus der
>> MySQL-Welt kommend sehr schnell das Äquivalent in PostgreSQL findet.
>
> In MySQL kann ich ueber mysql.db.*_priv die Zugriffsrechte fuer eine
> komplette Datenbank setzen, auch fuer Tabellen, die erst in der Zukunft
> angelegt werden.
>
> In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all tables"
> gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen hinzu, muss
> ich die Zugriffsrechte noch einmal explizit setzen, was im Fall mehrerer
> Datenbanken durchaus laestig sein kann.
Du suchst "ALTER DEFAULT PRIVILEGES"
> On Wed, 24 Oct 2012 02:21:49 Oliver Sch@d wrote:
>> http://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL
>
>> Es gibt da noch mehr vergleichende Webseiten, mit denen man aus der
>> MySQL-Welt kommend sehr schnell das Äquivalent in PostgreSQL findet.
>
> In MySQL kann ich ueber mysql.db.*_priv die Zugriffsrechte fuer eine
> komplette Datenbank setzen, auch fuer Tabellen, die erst in der Zukunft
> angelegt werden.
>
> In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all tables"
> gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen hinzu, muss
> ich die Zugriffsrechte noch einmal explizit setzen, was im Fall mehrerer
> Datenbanken durchaus laestig sein kann.
http://www.postgresql.org/docs/current/interactive/sql-alterdefaultprivileges.html
> Habe ich da etwas uebersehen?
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
Andreas Scherbaum
Oct 24, 2012, 6:06:54 PM10/24/12
to
>> tut genau das mit User "Stefan" als Besitzer (großes Oh für "owner" ).
>
> Der Besitzer eines neu angelegten Objekts in dieser DB ist aber trotzdem
> der Anleger des Objektes, nicht der Besitzer der DB.
>
> In PG kann man mit Rollen auf der Datenbankebene Laufzeitparameter
> festlegen, aber keine Privilegien an neu erstellte Objekte automatisch
> zuweisen.
Du suchst "ALTER DEFAULT PRIVILEGES".
> Der Besitzer eines neu angelegten Objekts in dieser DB ist aber trotzdem
> der Anleger des Objektes, nicht der Besitzer der DB.
>
> In PG kann man mit Rollen auf der Datenbankebene Laufzeitparameter
> festlegen, aber keine Privilegien an neu erstellte Objekte automatisch
> zuweisen.
Siegfried Schmidt
Oct 25, 2012, 12:37:28 AM10/25/12
to
Andreas Scherbaum schrieb:
> Du suchst "ALTER DEFAULT PRIVILEGES".
Stimmt. Gibts schon seit 9.0 und war mir bislang nicht aufgefallen.
Siegfried
> Du suchst "ALTER DEFAULT PRIVILEGES".
Siegfried
Peter Blancke
Oct 25, 2012, 5:04:07 AM10/25/12
to
Am 2012-10-23, Volker Englisch <v.englis...@rsli.de> schrieb:
> Florian Weimer <f...@deneb.enyo.de> wrote:
> Ich habe in pg_hba.conf
In Debian/Squeeze (PostgreSQL 8.4.13) finden sich dort dazu folgende
Eintraege:
,----
| local all all ident
| host all all 127.0.0.1/32 md5
| host all all ::1/128 md5
`----
> jetzt aus "trust" "password" gemacht,
Vielleicht statt "password" lieber gleich "md5" nehmen, die Doku
spricht:
,----
| Note that "password" sends passwords in clear text; "md5" is
| preferred since it sends encrypted passwords.
`----
"md5" klingt da irgendwie "gesuender".
Grusz,
Peter Blancke
--
Hoc est enim verbum meum!
> Florian Weimer <f...@deneb.enyo.de> wrote:
> Ich habe in pg_hba.conf
In Debian/Squeeze (PostgreSQL 8.4.13) finden sich dort dazu folgende
Eintraege:
,----
| local all all ident
| host all all 127.0.0.1/32 md5
| host all all ::1/128 md5
`----
> jetzt aus "trust" "password" gemacht,
spricht:
,----
| Note that "password" sends passwords in clear text; "md5" is
| preferred since it sends encrypted passwords.
`----
"md5" klingt da irgendwie "gesuender".
Grusz,
Peter Blancke
--
Hoc est enim verbum meum!
Andreas Scherbaum
Oct 25, 2012, 6:31:00 AM10/25/12
to
oder deine Übertragung schon verschlüsselt ist, brauchst du das
Passwort nicht noch mal verschlüsseln.
Ansonsten macht aber "md5" durchaus Sinn.
Stefan Froehlich
Oct 25, 2012, 9:57:20 AM10/25/12
to
On Thu, 25 Oct 2012 00:06:02 Andreas Scherbaum wrote:
> > In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all
> > tables" gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen
> > hinzu, muss ich die Zugriffsrechte noch einmal explizit setzen, was im
> > Fall mehrerer Datenbanken durchaus laestig sein kann.
> Du suchst "ALTER DEFAULT PRIVILEGES"
Stimmt.
> > In PostgreSQL habe ich als Aequivalent bislang nur "grant * on all
> > tables" gefunden, was aber kuerzer greift: fuege ich spaeter Tabellen
> > hinzu, muss ich die Zugriffsrechte noch einmal explizit setzen, was im
> > Fall mehrerer Datenbanken durchaus laestig sein kann.
> Du suchst "ALTER DEFAULT PRIVILEGES"
> > Habe ich da etwas uebersehen?
> Ja
Besten Dank, das erspart in weiterer Folge einiges an Wartungsaufwand.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Volker Englisch
Oct 25, 2012, 4:22:01 PM10/25/12
to
Am 25.10.12 schrieb Peter Blancke:
außerhalb. Muß ich mir da trotzdem Sorgen machen?
V*
> Am 2012-10-23, Volker Englisch <v.englis...@rsli.de> schrieb:
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>
>> Ich habe in pg_hba.conf
>
> In Debian/Squeeze (PostgreSQL 8.4.13) finden sich dort dazu folgende
> Eintraege:
>
> ,----
>| local all all ident
>| host all all 127.0.0.1/32 md5
>| host all all ::1/128 md5
> `----
>
>> jetzt aus "trust" "password" gemacht,
>
> Vielleicht statt "password" lieber gleich "md5" nehmen, die Doku
Das ganze spielt sich alles nur lokal ab (localhost). Kein Zugriff von
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>
>> Ich habe in pg_hba.conf
>
> In Debian/Squeeze (PostgreSQL 8.4.13) finden sich dort dazu folgende
> Eintraege:
>
> ,----
>| local all all ident
>| host all all 127.0.0.1/32 md5
>| host all all ::1/128 md5
> `----
>
>> jetzt aus "trust" "password" gemacht,
>
> Vielleicht statt "password" lieber gleich "md5" nehmen, die Doku
außerhalb. Muß ich mir da trotzdem Sorgen machen?
V*
Volker Englisch
Oct 25, 2012, 4:19:18 PM10/25/12
to
Am 24.10.12 schrieb Siegfried Schmidt:
Daten aus MySQL verfüttert, in denen das Datum durchweg "YYYY-MM-DD"
ist, und so wird es ohne Konvertierung auch ausgegeben...
V*
Siegfried Schmidt
Oct 26, 2012, 7:49:59 AM10/26/12
to
Volker Englisch schrieb:
> Die locale ist eigentlich richtig gesetzt, aber ich habe an postgreSQL
> Daten aus MySQL verfï¿œttert, in denen das Datum durchweg "YYYY-MM-DD"
kannst das global in der conf oder individuell fï¿œr jede Client-Verbindung
ï¿œndern.
Siegfried
> Die locale ist eigentlich richtig gesetzt, aber ich habe an postgreSQL
> ist, und so wird es ohne Konvertierung auch ausgegeben...
Dann wird im datestyle wahrscheinlich 'ISO' an erster Stelle stehen. Du
kannst das global in der conf oder individuell fï¿œr jede Client-Verbindung
ï¿œndern.
Siegfried
Florian Weimer
Oct 26, 2012, 5:16:14 PM10/26/12
to
* Andreas Scherbaum:
>> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>> historische Voreinstellungen. --auth=peer stellt das ab.
>
> Liegt im Regelfall eher daran was deine Distribution da einstellt.
Ich ging deswegen von einem manuellen Aufruf von pg_hba.conf aus.
FreeBSD scheint aber den Default nicht zu �berschreiben.
(Und noch etwas: Ich sah neulich, da� Fedora den Socket von /tmp nach
/var/run umzog. Es gibt also noch Fortschritt.)
>> Das liegt an den Einstellungen in pg_hba.conf. initdb hat unsichere
>> historische Voreinstellungen. --auth=peer stellt das ab.
>
> Liegt im Regelfall eher daran was deine Distribution da einstellt.
FreeBSD scheint aber den Default nicht zu �berschreiben.
(Und noch etwas: Ich sah neulich, da� Fedora den Socket von /tmp nach
/var/run umzog. Es gibt also noch Fortschritt.)
0 new messages