Re: BUG #3319: Superuser can't revoke grants on a schema given by aother user
От | Pedro Gimeno Fortea |
---|---|
Тема | Re: BUG #3319: Superuser can't revoke grants on a schema given by aother user |
Дата | |
Msg-id | 1180560650l.8394l.4l@dirtecnica.formauri.es обсуждение исходный текст |
Ответ на | Re: BUG #3319: Superuser can't revoke grants on a schema given by aother user (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I got a broader view of the whole picture and obviously my proposal=20=20 that the superuser automatically revokes the privileges granted by all=20= =20 others does not make sense. So let me state the solutions I propose to=20= =20 the problem I'm facing: (1) In the documentation for REVOKE, after the paragraph that begins=20=20 with "A user can only revoke privileges that were granted directly by=20=20 that user." add another paragraph similar to this: "The rule stated in the previous paragraph is also valid for the=20=20 superuser. The superuser can however issue SET ROLE commands to revoke=20= =20 the privileges granted by the desired users." (2) In the documentation for REVOKE, state clearly that REVOKE will=20=20 fail silently if the user issuing the command is not the grantor. Do so=20= =20 preferably near the bit about the superuser above. (3) When issuing the command REVOKE <PRIV> ON <OBJ> FROM <USER>, issue=20= =20 a NOTICE or WARNING message when, after executing it, the user <USER>=20=20 has still privilege <PRIV> on object <OBJ>. (4) Add a GRANTED BY <USER> extension to the REVOKE command which=20=20 allows to revoke permissions given by other users, where <USER> can be=20= =20 ALL. Obviously it would be subject to other checks which could make it=20= =20 fail. Of course 2 and 3 are mutually exclusive. Solution 1+2 is the simplest,=20= =20 as it only involves documentation. Solution 1+3 would be enough to=20=20 avoid most surprises. Solution 1+3+4 would be ideal.
В списке pgsql-bugs по дате отправления: