From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | The Hermit Hacker <scrappy(at)hub(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE DATABASE WITH OWNER '??'; |
Date: | 2000-05-09 22:18:26 |
Message-ID: | 15523.957910706@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The difficulty with putting the control over this into the SQL environment
> is two-fold:
> 1) You have a bootstrapping problem, because how are you going to set
> these privileges if you can't connect?
Presumably the database superuser can connect to anything anytime, and
I'd also expect a newly-minted database to be preconfigured to let its
owner in. (We could debate whether that privilege should be revokable,
but worst case is the owner goes to the dbadmin and admits what an idiot
he's been ;-).) So this doesn't seem like a major objection.
> 2) You don't necessarily want to start up a new backend for every rogue
> connection attempt.
True, but we can still expect the postmaster to have done the same
amount of connection checking it does now, so the worst forms of abuse
can be prevented. Bear in mind also that things like bad database name
are usually detected by the newly-started backend, so unless you run a
much tighter than normal pg_hba.conf, you have some exposure here
already. I think having the backend reject an unauthorized connection
attempt from a user that the postmaster has previously checked to be
known to the database is not so bad.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Travis Bauer | 2000-05-09 22:45:12 | Problems compiling version 7 |
Previous Message | Oliver Elphick | 2000-05-09 21:33:36 | Groups and schemas (was: You're on SecurityFocus.com...) |