Dear August
Thank you for your reply.
On 4/25/07, August Zajonc <augustz@augustz.com> 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