"Robert Haas" <[EMAIL PROTECTED]> writes:
> I like the idea of a WITH ROW SECURITY option to enable row-level
> security - that way, tables that don't need it don't have to pay for
> it, but I like the idea of storing a full ACL, as KaiGai proposed,
> rather than just a single role. Seems much more powerful.
... and even more ill-defined.
Consider the following scenario:
1. User alice is a member of role admin.
2. User bob creates a table BT and puts some rows in it that are
supposedly only visible to role admin. He also grants REFERENCE
permission to alice. (Let's suppose he does that directly, not via
the admin role; though the other case is interesting too.)
3. User alice creates a table AT with an FK dependency on BT and then
makes some entries that depend on the only-visible-to-admin rows in BT.
She is allowed to do this, obviously.
4. User charlie revokes alice's membership in admin.
Now what? Alice's FK constraint is violated, according to the rules
KaiGai proposes. Shall REVOKE have to grovel through every table in the
database looking for possible violations ... and of course locking the
entire DB against writes while it does it? That's not gonna fly. I
also note that the failure would expose knowledge of the contents of BT
and AT to charlie, which might not be thought desirable either.
This problem is bad enough if row visibility is defined just by role
membership. I shudder to think of trying to make it a general ACL.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
