Thread: Fwd: Bug with groups and access permissions (7.0.0RC1): more information

Well, I have more information about theses bugs:

> It seems there is a 'referential integrity' bug with groups and permissions:
>
> db=> CREATE USER user1;
> CREATE USER
> db=> CREATE GROUP group1 WITH SYSID 4 USER user1;
> CREATE GROUP
> db=> CREATE TABLE table1 (field1 integer PRIMARY KEY);
> CREATE
> db=> REVOKE ALL ON table1 FROM PUBLIC;
> CHANGE
> db=> GRANT ALL ON table1 TO GROUP group1;
> CHANGE
> db=> DROP GROUP group1;
> DROP GROUP
> \z
> NOTICE:  get_groname: group 4 not found
> The connection to the server was lost. Attempting reset: Failed.
> !=>

It seems that dropping the group don't delete it from the tables permissions
(acl).
Then, when Postgresql try to display them, it can't find the name of the dropped
group.

> db=> DROP USER userx;
> ERROR: group groupy does not exist.
> db=> SELECT * from PG_GROUP;
> ...
> groupy | 5 | {1,4}
> ...
> db=> DROP GROUP groupy;
> DROP
>

Apparently, this tied with databases:

- Create a group 'foo' in the database 'foodb':
    \c foodb postgres
    CREATE GROUP foo;

- Add the user 'userfoo' in this group:
    ALTER GROUP foo ADD USER 'userfoo;'

- Reconnect to database 'bardb':
    \c bardb

- Trying to drop the user 'userfoo' leads to "group foo does not exist":
    DROP USER userfoo;

But either dropping 'userfoo' from 'foodb' or dropping group 'foo' from 'bardb'
works!

Guillaume Perréal - Stagiaire MIAG
Cemagref (URH), Lyon, France
Tél: (+33) 4.72.20.87.64

This stuff all seems to be fixed in current sources.  There may be a
post-release patch or two involved, but the bulk of the fixes are in
7.0 final.

            regards, tom lane