Re: BUG #1161: User permissions are kept, even if user is
От | Fabien COELHO |
---|---|
Тема | Re: BUG #1161: User permissions are kept, even if user is |
Дата | |
Msg-id | Pine.LNX.4.60.0406081209260.27846@sablons.cri.ensmp.fr обсуждение исходный текст |
Ответ на | BUG #1161: User permissions are kept, even if user is dropped ("PostgreSQL Bugs List" <pgsql-bugs@postgresql.org>) |
Список | pgsql-bugs |
Hi, > since the dropped user is very unlikely to be resurrected, the correct=20 > answer would be to remove all dangling permissions on the existing=20 > objects. Using a sequence would only clutter the system with unused=20 > grants. What about ownership? would that mean you want to delete the object? > Since DROP USER is only rarely used, it would be okay if this operation > is expensive. The problem is not the drop being expensive. The problem is that tables=20 are managed withing a database, and you cannot access a database without=20 connecting to it, and it is not an option to connect to other databases to= =20 do such a thing on any command. So when you drop a user, you do not have access to acl so as to fix them=20 (i.e. removing dandling permissions). That may be done on the current database, but that is all. Think of the system. That would mean deleting/fixing all files owned by a= =20 user when the user is removed, on whatever partition, maybe not even=20 mounted on the host. Not really possible, and not a good idea to try... So it looks much simpler to fix the real issue by avoiding the userid to=20 be reused. The dandling permission cost is low. Also, I would not be happy if deleting a user would mean deleting all=20 objects owned by that user, esp. as I cannot know simply what they are. > At least a select statement to gather these dangling permissions > should be available in the documentation. It is a per database stuff: you must do it for every database. This very=20 query is in the todo list of my pgadvisor stuff (see=20 http://pg-advisor.projects.postgresql.org/). However I need some non=20 available support from the backend that was rejected when I submitted a patch (8 lines of code:-). So it is unlikely to be added soon. > PS: Btw: I seem to be unable to locate the TODO-list that should be > referenced before posting a bug-report. Any hints? simply follow "bug reporting guidelines" on http://www.postgresql.org/ ? --=20 Fabien COELHO _ http://www.cri.ensmp.fr/~coelho _ Fabien.Coelho@ensmp.fr CRI-ENSMP, 35, rue Saint-Honor=E9, 77305 Fontainebleau cedex, France phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08} ________ All opinions expressed here are mine _________
В списке pgsql-bugs по дате отправления: