> >It sounds like table || column is the check, so table implies
> >all of columns. ie, revoking a column permission does nothing
> >unless TABLE permission is also revoked.
>
> IF this will be implemented as suggested here, it will become
extremely
> counter-intuitive. Its just like you have access to a file if you have
> (explicitly been granted) access to the file OR to its constaining
> directory (thus sort of implicit).
>
> My strongly opinion is that, REVOKE column-level priviledge should
> revoke access to that column, in effect it should reduce the
table-level
> grant to column-level grants.
I think this causes problems when columns are added to the table. If
table X has columns A, B, C, and D, and the user has access to A-C but
not D, then what happens when column E is added? Logically, if the user
started with table access and column D was revoked, then they should
have access to column E. But if they started with access to nothing and
were explicitly granted A-C, then they shouldn't.
You could solve this by having explicit positive and negative ACLs, i.e.
your permissions for a particular column are:
[table permissions] + [positive column permissions] - [negative column
permissions]
However, this is both more complicated and possibly imposes a
considerably larger performance penalty than the proposed design. In
the proposed design, if the appropriate table permissions are granted
(presumably the common case), we don't even need to look at the column
permissions. But with this design, we need to check every column for
negative permissions (unless we cache something at the table level that
tells us whether any per-column permissions exist). You'll also need a
more complicated grant/revoke syntax so that you can add a positive
permission, add a negative permission, or eliminate the per-column
setting entirely (whereas in the proposed design grant and revoke are
logically opposites of each other, that's not the case here).
...Robert