Dear August

Thank you for your reply.

On 4/25/07, August Zajonc <[EMAIL PROTECTED]> wrote:
Golden Liu wrote:
> 3. Before evaluating a SQL command, check column-level privilege.
> This is done AFTER checking table-level privilege. As I mentioned
> before, if table-level privilege is granted, it's not necessary to
> check column-level privilege.

Golden, this sounds good. I'm just a user.

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.

It also might be nice to specify some of the failure / usage modes.

ie, how does "SELECT * FROM Students" work if I don't have permission to
a column. Return all values except for forbidden ones? How does "SELECT
ForbiddenColumn FROM Students" work.

For "SELECT * FROM Students", I think this will just raise an error.
In PG, if you commit a command like "SELECT * FROM T1, T2" but do not
have permission to T2, PG will raise an error. For column, we should
do the same thing.
"SELECT ForbiddenColumn FROM Students" will raise an error too.

For INSERTS, they probably need to fail if you don't have permission to
non-null columns. What about columns with default values? Are inserts
permitted if you don't have permission to a column with default values?

For INSERTS, privilege check will just do on columns specified. For
table T with two columns, say C1 and C2, and C2 has a default value.
If you just have INSERT permission on C1, this will be right:
   INSERT INTO T(C1) VALUES (V1)
since you just specified C1. But this will raise an error:
   INSERT INTO T VALUES (V1, default)
since you specified C2 which you do not have permission to insert into.

Do you have a project page up somewhere? I wouldn't mind helping with
some of the documentation for example.

Good luck!

- August




Golden

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to