Tom Lane wrote: > "Robert Haas" <[EMAIL PROTECTED]> writes: >>> This is just a different syntax for KaiGai's label storage >>> implementation. It doesn't really answer any of the hard questions, >>> like what the heck is the behavior of foreign keys. > >> What do you find inadequate about KaiGai's answers to those hard questions? > > Mainly just that they're only one set of possible answers. If we're > thinking of baking a particular set of semantics into SQL syntax, > we'd better be darn sure that they are the right semantics --- both > in terms of widest usefulness, and in terms of not being stuck behind > the eight-ball if the SQL standards committee ever moves to standardize > a similar behavior.
If SQL standard adopts row-level security, it also welcomes for me. Please note that SE-PostgreSQL works orthogonally from the native access controls of PostgreSQL. I think it is usefulness to apply different security policies based on different rules, architecture and philosophy. > Another point is that the proposed behavior leaks quite a lot of > information, since it will fail operations on the basis of tuples that > supposedly aren't visible to the invoking user. While I admit that it's > hard to see an alternative if we're to preserve FK integrity, I have to > worry that this definition isn't going to satisfy the tin-foil-hat > brigade that are supposed to be the main users of SEPostgres. If the > goal is "you don't know the row is there", this doesn't seem to meet it. Yes, it is just a limitation of SE-PostgreSQL's row-level access control. However, we can avoid actual matter by applying alternative keys for these kind of databases, as Bruce mentioned before. No need to say, it is a thing to be described in documentation, and end-users should make their decison. One considerable option provided to end-user is to add a switch called as "boolean" to allow all of row-level access controls. > I wonder whether it wouldn't make more sense to pursue restrictions > at some different level. SQL already has the concept of REFERENCE > permission, ie, not just anybody can make a foreign key reference to > your table. Maybe there has to be a rule that you can't make an FK > reference to a table you don't have full read permissions for. The > restrictions in the other direction (what can PK table's owner find out > about FK table's contents) are pretty interesting too. SE-PostgreSQL focuses on the fact client can see the PK refered. It is different from native SQL's permission, but it think it is just a difference between security models. It is worthwhile to achieve secure state of databases in different levels. For example, privileged database user can override all of access controls. It is a unignorable risk, as root is considered as a risk in operating system. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
