From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dropping a user causes pain (#2) |
Date: | 2003-08-12 07:51:04 |
Message-ID: | Pine.LNX.4.56.0308120946280.1394@krusty.localdomain |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> The advantage here is that the sysid assigned to the user would remain
> present in pg_shadow and couldn't accidentally be assigned to a new
> user. This would prevent the problem of new users "inheriting"
> permissions and even object ownership from deleted users due to chance
> coincidence of sysid.
But how does one actually get rid of the privileges?
Btw., the problem is going to get worse if we get nested roles, roles with
grant options, and possibly other parts of the enhanced privilege
facilities. For example, if you remove a user from a role/group, you
would need to search the entire database cluster for any privileges
granted through that group that this user had used to create some kind of
permanent state. I'm not sure if we want to cover all of these cases with
various "this link no longer exists" flags, especially since later on the
link could be reestablished.
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-08-12 07:53:11 | Re: dropping a user causes pain (#2) |
Previous Message | Peter Eisentraut | 2003-08-12 07:30:20 | Re: Change Request: \pset pager off in pg_dumpall |