From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Gevik Babakhani <pgdev(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Please advice TODO Item pg_hba.conf |
Date: | 2006-04-23 23:09:46 |
Message-ID: | 18720.1145833786@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Gevik Babakhani wrote:
>> At this moment the owner of the database CAN REVOKE himself form the
>> ACL_OBJECT_DATABASE. If the implementation above is acceptable then I
>> can work on this one :)
> Hmm, what do you want to do about it? ISTM the owner should be able to
> revoke the privilege from himself ...
Agreed. You can revoke all your own ordinary privileges on a table,
for example, and it would be just weird to not be able to do so for
a database.
> (Maybe we could raise a WARNING
> whenever anyone revokes the last CONNECT privilege to a database, so
> that he can GRANT it to somebody before disconnecting.)
Since (a) you could connect to a different DB, eg template1, and restore
the privilege; and (b) superusers will get past this check anyhow,
I see no need for special pushups to prevent revoking CONNECT.
> Also I'm not sure if we have discussed what's the default (initial)
> privilege state. Do we want PUBLIC to have CONNECT privilege?
It must, else the behavior is not backwards compatible.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-23 23:14:29 | Re: Please advice TODO Item pg_hba.conf |
Previous Message | Alvaro Herrera | 2006-04-23 22:43:30 | Re: Protocol Message Graph |