[postgresql] user owner maken van database

[Verwijderd]

Ik ben al de hele dag aan het klooien met postgresql. De documentatie ben ik ook al door. Maar het volgende lukt mij niet:

Ik wil netzoals met mysql, een user aanmaken en deze toegang willen geven tot (alleen) zijn eigen database. Ik had gehoopt dat dat zou kunnen met 'alter database dbname set owner ownername;' Maar niet dus.

Wie weet hoe het wel moet?

[blaataaps]

Toch krijg ik als ik google op "change owner database postgresql" de volgende link als eerst hit: http://www.postgresql.org...ve/sql-alterdatabase.html waar volgens mij letterlijk de oplossing staat?

[Verwijderd]

blaataaps schreef op 02 juni 2004 @ 12:46:
Toch krijg ik als ik google op "change owner database postgresql" de volgende link als eerst hit: http://www.postgresql.org...ve/sql-alterdatabase.html waar volgens mij letterlijk de oplossing staat?

Nope, daar staat niet hoe ik de owner kan veranderen (of hoe ik de privileges moet granten)... Dat stukje documentatie had ik ook al gehad...

[blaataaps]

Helemaal onderaan staat anders toch echt "How to change the owner of a database?" met een letterlijk stuk code dat hier prima werkt.

[ Voor 6% gewijzigd door blaataaps op 02-06-2004 12:53 ]

[Verwijderd]

Ik had die user contrinuted notes niet gezien, maar ook dat werkt niet:

mydb-# UPDATE pg_database SET datdba = (SELECT usesysid FROM pg_shadow WHERE usename = 'test') WHERE datname = 'test;
ERROR: parser: parse error at or near "datdba"

[blaataaps]

De code werkt hier prima:

test=# UPDATE pg_database SET datdba = (SELECT usesysid FROM pg_shadow WHERE usename = 'test') WHERE datname = 'test';
UPDATE 1
test=#

Je moet natuurlijk ook de ' aan het einde van je commando sluiten, 'test; gaat natuurlijk niet werken.

[Verwijderd]

Ik wil je alleen voor 1 ding waarschuwen:
als je dit doet, is het niet meer mogelijk een pg_dumpall output in 1 keer te importeren, tenzij je de eigenaar van de database create database rechten geeft.

Hoe je dit kan oplossen:
• cat dump|sed "s/NOCREATEDB/CREATEDB/g">dump.fixed
• dump.fixed importeren in psql
• update pg_shadow set usecreatedb='f' where usename != 'postgres';

[Wilke]

Dit heeft sowieso niks met NOS te maken maar alleen met SQL. Daarom verplaats ik 'm naar Programming & Webscripting (en help ik je hopen dat 'ie daar open blijft, want het ziet er naar uit dat dit toch echt wel in de handleiding staat).

[blaataaps]

Verwijderd schreef op 02 juni 2004 @ 13:07:
Ik wil je alleen voor 1 ding waarschuwen:
als je dit doet, is het niet meer mogelijk een pg_dumpall output in 1 keer te importeren, tenzij je de eigenaar van de database create database rechten geeft.

Hoe je dit kan oplossen:
• cat dump|sed "s/NOCREATEDB/CREATEDB/g">dump.fixed
• dump.fixed importeren in psql
• update pg_shadow set usecreatedb='f' where usename != 'postgres';

Die laatste regel lijkt me niet handig als sommige users (behalve de postgres-user) ook CREATEDB-rechten moeten hebben of niet?
Die kun je achteraf ook per user terugzetten in plaats van de rechten van iedereen afpakken die niet posgtres is.

[Verwijderd]

blaataaps schreef op 02 juni 2004 @ 13:04:
De code werkt hier prima:

[...]

Je moet natuurlijk ook de ' aan het einde van je commando sluiten, 'test; gaat natuurlijk niet werken.

dat had ik ook, verkeerd geedit hier...

[Verwijderd]

Ok nou wat ik eigenlijk wil doen, is gewoon wat je met mysql ook doet. Een user bepaalde rechten (select, update etc) geven tot een bepaalde database. Maar ik kon niet vinden hoe dat met grant kon/moest, en daarom leek het me logisch dat je dan de user eigenaar moet maken van de database. Maar misschien is mijn denkwijze wel fout?

[cameodski]

Verwijderd schreef op 02 juni 2004 @ 13:13:
Ok nou wat ik eigenlijk wil doen, is gewoon wat je met mysql ook doet. Een user bepaalde rechten (select, update etc) geven tot een bepaalde database. Maar ik kon niet vinden hoe dat met grant kon/moest, en daarom leek het me logisch dat je dan de user eigenaar moet maken van de database. Maar misschien is mijn denkwijze wel fout?

Die denkwijze is inderdaad fout. Hoe wil je dat bijvoorbeeld oplossen als je twee users rechten wilt geven?
Ik weet zo ongeveer niks van postgresql, maar het lijkt me dat grant inderdaad gewoon werkt.

[Verwijderd]

Inderdaad.... maar als ik kijk in de documentatie, dan zie ik alleen maar hoe ik users kan granten om 1 specifieke tabel te lezen/updaten etc. Niet hoe je dat met een complete database moet doen. Ook dit werkt niet:

mydb=# grant select on testdb to dbuser;
ERROR: relation "testdb" not found

De database testdb bestaat wel...

[jochemd]

Verwijderd schreef op 02 juni 2004 @ 13:22:
Inderdaad.... maar als ik kijk in de documentatie, dan zie ik alleen maar hoe ik users kan granten om 1 specifieke tabel te lezen/updaten etc. Niet hoe je dat met een complete database moet doen.

Door het commando te herhalen voor elk object in de database.

[Verwijderd]

jochemd schreef op 02 juni 2004 @ 13:52:
[...]
Door het commando te herhalen voor elk object in de database.

Dat is toch enorm onzinnig? De user kan dus nooit tabellen dan aanmaken zonder dat de superuser eerst gaat granten..... moet toch wel een oplossing zijn dat een user gewoon volledig recht heeft in zijn eigen database?

[jochemd]

Verwijderd schreef op 02 juni 2004 @ 13:56:
[...]

Dat is toch enorm onzinnig? De user kan dus nooit tabellen dan aanmaken zonder dat de superuser eerst gaat granten.....

Als een user geen owner is zal hij eerst van iemand CREATE rechten op het schema moeten krijgen voordat hij er tabellen in mag aanmaken. Het is toch hardstikke logisch dat dat recht eerst expliciet moet worden toegekend aan anderen dan de owner?

moet toch wel een oplossing zijn dat een user gewoon volledig recht heeft in zijn eigen database?

Als het zijn database is is hij dus owner en heeft hij alle rechten.

[cameodski]

Verwijderd schreef op 02 juni 2004 @ 13:56:
[...]

Dat is toch enorm onzinnig? De user kan dus nooit tabellen dan aanmaken zonder dat de superuser eerst gaat granten..... moet toch wel een oplossing zijn dat een user gewoon volledig recht heeft in zijn eigen database?

Per user aparte tabellen aanmaken is NOOIT een goed oplossing. Als die user ergens anders gaat werken, slingeren er allemaal tabellen rond en wat moet je daarmee.

In een database kun je het beste alle objecten aan dezelfde user koppelen en deze mag databasewijzigingen doorvoeren en rechten uitdelen.
De gewone users moeten helemaal niet de mogelijkheid hebben om allerlei troep toe te voegen.

[JaQ]

cameodski schreef op 02 juni 2004 @ 14:59:
[...]

Per user aparte tabellen aanmaken is NOOIT een goed oplossing. Als die user ergens anders gaat werken, slingeren er allemaal tabellen rond en wat moet je daarmee.

In een database kun je het beste alle objecten aan dezelfde user koppelen en deze mag databasewijzigingen doorvoeren en rechten uitdelen.
De gewone users moeten helemaal niet de mogelijkheid hebben om allerlei troep toe te voegen.

voor een productieomgeving wel ja... in een ontwikkelomgeving juist niet. Ik verafschuw het als ik weer een facist van een DBA tegen kom die denkt leuk te zijn door je create table commando's te blokken. (Net zoals het bloedje irritant is als je geen rootrechten, of van toepassing zijnde sudo rechten krijgt als je ze wel nodig hebt, en dus voor ieder wissewasje iemand moet lastigvallen)

Vanaf 7.3 ondersteund postgresql ook schema's (en dan is het ineens wel erg leuk om een user in 1 schema te laten werken, verder synonymen). Anyway, ik vermoed dat de aard van het probleem er in ligt dat je of niet als superuser bent ingelogt (geen superuser, geen admin rechten, geen grant mogelijkheid), of je niet in de pg_catalog bent ingelogt (of hoe die opper-db ook heet) .

[cameodski]

DrFrankenstoner schreef op 02 juni 2004 @ 15:20:
[...]
voor een productieomgeving wel ja... in een ontwikkelomgeving juist niet. Ik verafschuw het als ik weer een facist van een DBA tegen kom die denkt leuk te zijn door je create table commando's te blokken. (Net zoals het bloedje irritant is als je geen rootrechten, of van toepassing zijnde sudo rechten krijgt als je ze wel nodig hebt, en dus voor ieder wissewasje iemand moet lastigvallen)

In een ontwikkelomgeving hangt het ervan af hoe groot je projectteam is en hoe het met de rolverdeling ligt.
Maar tijdens de ontwikkeling is het ook verstandig om de verantwoordelijkheid bij een beperkt aantal mensen te leggen. Verder vraag ik me wel af hoe je erbij komt dat een tabel toevoegen een wissewasje is. Een goed ontwerp is erg belangrijk en dan zouden tabelwijzigingen niet al teveel meer mogen voorkomen.

[jochemd]

mydb-# UPDATE pg_database SET datdba = (SELECT usesysid FROM pg_shadow WHERE usename = 'test') WHERE datname = 'test;
ERROR: parser: parse error at or near "datdba"

Ik zie trouwens al wat er hier fout gaat. Kijk eens goed naar je prompt, dat is een continuation prompt. Je was al een commando gestart op de regel(s) hiervoor.

[Verwijderd]

jochemd schreef op 02 juni 2004 @ 15:45:
[...]
Ik zie trouwens al wat er hier fout gaat. Kijk eens goed naar je prompt, dat is een continuation prompt. Je was al een commando gestart op de regel(s) hiervoor.

Ik had het inmiddels ook al voor elkaar gekregen, maar niet met het effect dat ik had gehoopt.

Er komen meerdere users met meerdere databases op te draaien, het is niet de bedoeling dat user a toegang heeft tot de database van user b, wat op dit moment wel zo is. Zelfs als user a niet de owner is van database b....

Wie weet raad?

[jochemd]

Verwijderd schreef op 02 juni 2004 @ 15:55:
Er komen meerdere users met meerdere databases op te draaien, het is niet de bedoeling dat user a toegang heeft tot de database van user b, wat op dit moment wel zo is. Zelfs als user a niet de owner is van database b....

De simpelste manier is middels pg_hba.conf zorgen dat ze niet kunnen connecten. Verder kan je ook alle rechten op schema's revoken, dan kunnen ze wel connecten met een database maar niet met schema's in de database.

[Verwijderd]

Ok, daar was ik toevallig al een beetje mee bezig, maar wat is nou de beste manier; er word vanaf een extern ip geconnect waar geen ident op draait. Nu heb ik het zo maar dit werkt helaas niet:


host dbname 123.123.123.123 255.255.255.255 password

[jochemd]

Verwijderd schreef op 02 juni 2004 @ 16:32:
host dbname 123.123.123.123 255.255.255.255 password

Je mist een username. De syntax is:

code:

connectietype   database   username   ipaddress   netmask   authenticatiemethode

[Verwijderd]

jochemd schreef op 02 juni 2004 @ 16:43:
[...]
Je mist een username. De syntax is:

code:

connectietype   database   username   ipaddress   netmask   authenticatiemethode

Ik draai versie 7.2.1, dan heb je nog geen username....

[jochemd]

Verwijderd schreef op 02 juni 2004 @ 16:52:
[...]

Ik draai versie 7.2.1, dan heb je nog geen username....

Het is misschien een klein beetje relevant om meteen te vermelden dat je een versie draait die niet meer supported is en vol zit met known bugs. Ik zou eerst maar eens upgraden (desnoods naar 7.2.4 zodat je in elk geval alle bugfixes hebt, maar liever naar 7.4.2). Er is nogal wat veranderd en volgens mij is daarbij ook het permissies model onder handen genomen (het CREATE privilege is volgens mij van versie 7.4).

[Verwijderd]

Okee, ik heb hem geupgrade naar 4.2.1, alleen nu zit ik met een ander probleem (zucht). Vanaf localhost kan ik connecten, maar niet vanaf een andere computer. Ik heb het volgende helemaal bovenaan in de pg_hba.conf gezet:

host all all 0.0.0.0 0.0.0.0 trust

Puur om te testen, maar toch krijg ik geen verbinding (foutmelding: de externe computer heeft de verbinding actief verbroken)...

[Verwijderd]

http://groups.google.nl/g...g.adl.ardec.com.au&rnum=6