From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Port Reports: UnixWare/Failure/Priviledge Test |
Date: | 2003-10-31 23:16:41 |
Message-ID: | 20979.1067642201@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:
> Tom Lane writes:
>> nothing happens, because the revoke is implicitly assumed to mean
>> "revoke whatever privileges I granted", and Larry's superuser hasn't
>> granted any. The public privileges on language SQL were granted by
>> user postgres, and they remain in force. So the later CREATE FUNCTION
>> that the test expects to fail, succeeds.
>>
>> Is this a bug, or is it correct-per-spec behavior?
> It's correct.
After chewing on it further, I decided that the spec is unable to
provide any useful guidance, because it hasn't got the concept of
superuser. It is however clear that having superusers generate their
own grants to someone else's object is not within the privilege model of
the spec. I think the solution I applied this afternoon (pretend that
superusers are the object owner for GRANT/REVOKE purposes) is a
reasonable answer.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-10-31 23:27:02 | Re: 7.4RC1 planned for Monday |
Previous Message | Peter Eisentraut | 2003-10-31 23:01:43 | Re: Port Reports: UnixWare/Failure/Priviledge Test |