Thread: column level privileges
(try 2) Here is an updated patch that applies to HEAD. I will update the wiki. (What is the maximum attachment size that -patches will accept?) cheers andrew I wrote: > > This patch by Golden Lui was his work for the last Google SoC. I was > his mentor for the project. I have just realised that he didn't send > his final patch to the list. > > I guess it's too late for the current commit-fest, but it really needs > to go on a patch queue (my memory on this was jogged by Tom's recent > mention of $Subject). > > I'm going to see how much bitrot there is and see what changes are > necessary to get it to apply. > > > ------------- > Here is a README for the whole patch. > > According to the SQL92 standard, there are four levels in the > privilege hierarchy, i.e. database, tablespace, table, and column. > Most commercial DBMSs support all the levels, but column-level > privilege is hitherto unaddressed in the PostgreSQL, and this patch > try to implement it. > > What this patch have done: > 1. The execution of GRANT/REVOKE for column privileges. Now only > INSERT/UPDATE/REFERENCES privileges are supported, as SQL92 specified. > SELECT privilege is now not supported. This part includes: > 1.1 Add a column named 'attrel' in pg_attribute catalog to store > column privileges. Now all column privileges are stored, no matter > whether they could be implied from table-level privilege. > 1.2 Parser for the new kind of GRANT/REVOKE commands. > 1.3 Execution of GRANT/REVOKE for column privileges. Corresponding > column privileges will be added/removed automatically if no column is > specified, as SQL standard specified. > 2. Column-level privilege check. > Now for UPDATE/INSERT/REFERENCES privilege, privilege check will be > done ONLY on column level. Table-level privilege check was done in the > function InitPlan. Now in this patch, these three kind of privilege > are checked during the parse phase. > 2.1 For UPDATE/INSERT commands. Privilege check is done in the > function transformUpdateStmt/transformInsertStmt. > 2.2 For REFERENCES, privilege check is done in the function > ATAddForeignKeyConstraint. This function will be called whenever a > foreign key constraint is added, like create table, alter table, etc. > 2.3 For COPY command, INSERT privilege is check in the function > DoCopy. SELECT command is checked in DoCopy too. > 3. While adding a new column to a table using ALTER TABLE command, set > appropriate privilege for the new column according to privilege > already granted on the table. > 4. Allow pg_dump and pg_dumpall to dump in/out column privileges. > 5. Add a column named objsubid in pg_shdepend catalog to record ACL > dependencies between column and roles. > 6. modify the grammar of ECPG to support column level privileges. > 7. change psql's \z (\dp) command to support listing column privileges > for tables and views. If \z(\dp) is run with a pattern, column > privileges are listed after table level privileges. > 8. Regression test for column-level privileges. I changed both > privileges.sql and expected/privileges.out, so regression check is now > all passed. > >
Attachment
Andrew Dunstan <andrew@dunslane.net> writes:
>> [ column privileges patch ]
I looked over this patch with the hope of applying it, but soon despaired.
It needs a great deal more work than I am willing to put into it during
commitfest. There are two absolutely critical must-fix problems:
1. The syntax implemented by the patch for GRANT and REVOKE has nothing
to do with that specified by the standard. The patch does, eg,
GRANT INSERT ON TABLE foo (col1, col2) TO somebody
but unless I have lost my ability to read BNF, what the spec demands is
GRANT INSERT (col1, col2) ON TABLE foo TO somebody
Admittedly the patch's syntax is more logical (especially if you
consider the possibility of multiple tables) but I don't think we
can go against the spec. This problem invalidates the gram.y changes
and a fair amount of what was done in aclchk.c.
2. The checking of INSERT/UPDATE permissions has been moved to a
completely unacceptable time/place, namely during parse analysis instead
of at the beginning of execution. This is unusable for prepared
queries, for example, and it also fails to apply permission checking
properly for UPDATEs of inheritance trees (only the parent would get
checked). This seems not very simple to fix :-(. By the time the plan
gets to the executor it is not clear which columns were actually
specified as targets by the user and which were filled in as defaults by
the rewriter or planner. One possible solution is to add a flag field
to TargetEntry to carry the information forward.
Some other points that need to be considered:
>> 1. The execution of GRANT/REVOKE for column privileges. Now only
>> INSERT/UPDATE/REFERENCES privileges are supported, as SQL92 specified.
>> SELECT privilege is now not supported.
Well, SQL99 has per-column SELECT privilege, so we're already behind
the curve here. The main problem again is to figure out a reasonable
means for the executor to know which columns to check. TargetEntry
markings won't help here. I thought about adding a bitmap to each
RTE showing the attribute numbers explicitly referenced in the query,
but I'm unsure if that's a good solution or not.
I'd be willing to leave this as work to be done later, since 90% of
the patch is just concerned with the mechanics of storing per-column
privileges and doesn't care which ones they are exactly. But it
needs to be on the to-do list.
>> 1.1 Add a column named 'attrel' in pg_attribute catalog to store
>> column privileges. Now all column privileges are stored, no matter
>> whether they could be implied from table-level privilege.
What this actually means, but doesn't say, is that there's no
table-level representation of INSERT/UPDATE privilege any more at all.
I think this is a pretty fundamental design error. In the first place
it bloats pg_attribute with data that's entirely redundant for the
"typical" case where per-column privileges aren't used. In the
second place it slows privilege checking for the typical case, since
instead of one check for the relation you have to do one for each
attribute. There are some other problems too, like having to extend
pg_shdepend to include an objsubid column, and some other places where
the patch has to do awkward things because it's now lacking table-level
information about privilege checks.
What I think would be a more desirable solution is that the table ACL
still sets the table-level INSERT or UPDATE privilege bit as long as
you have any such privilege. In the normal case where no per-column
privilege has been granted, the per-column attacl fields all remain
NULL and that's all you need. As soon as any per-column GRANT or
REVOKE is issued against a table, expand out the per-column ACLs to
match the previous table-level state, and then apply the per-column
changes. I think you'd need an additional pg_class flag column,
say "relhascolacls", to denote whether this has been done --- then
privilege checking would know it only needs to look at the column
ACLs when this field is set.
With this scheme we don't need per-column entries in pg_shdepend,
we can just reference the table-level bits as before. REVOKE would have
the responsibility of getting rid of per-column entries, if any, as a
followup to revoking per-table entries during a DROP USER operation.
Something else that needs to be thought about is whether system columns
have privileges or not. The patch seems to be assuming "not" in some
places, but at least for SELECT it seems like this might be sensible.
Also, you can already do COPY TO the OID column if any, so even without
any future extensions it seems like we've got the issue in front of us.
One other mistake I noted was that the version checks added in pg_dump
and psql are ">= 80300", which of course is obsolete now.
I'm not sure where we go from here. Your GSOC student has disappeared,
right? Is anyone else willing to take up the patch and work on it?
regards, tom lane
Tom, et al,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I'm not sure where we go from here. Your GSOC student has disappeared,
> right? Is anyone else willing to take up the patch and work on it?
I'm willing to take it up and work on it. I'm very interested in having
column-level privileges in PG. I also have some experiance in the
gram.y and ACL areas already that should make things go quickly. If
anyone else is interested/has resources, please let me know.
> Admittedly the patch's syntax is more logical (especially if you
> consider the possibility of multiple tables) but I don't think we
> can go against the spec. This problem invalidates the gram.y changes
> and a fair amount of what was done in aclchk.c.
Agreed, we need to use the SQL spec syntax.
> 2. The checking of INSERT/UPDATE permissions has been moved to a
> completely unacceptable time/place, namely during parse analysis instead
> of at the beginning of execution. This is unusable for prepared
> queries, for example, and it also fails to apply permission checking
> properly for UPDATEs of inheritance trees (only the parent would get
> checked). This seems not very simple to fix :-(. By the time the plan
> gets to the executor it is not clear which columns were actually
> specified as targets by the user and which were filled in as defaults by
> the rewriter or planner. One possible solution is to add a flag field
> to TargetEntry to carry the information forward.
I'll look into this, I liked the bitmap idea, personally.
> Some other points that need to be considered:
>
> >> 1. The execution of GRANT/REVOKE for column privileges. Now only
> >> INSERT/UPDATE/REFERENCES privileges are supported, as SQL92 specified.
> >> SELECT privilege is now not supported.
>
> Well, SQL99 has per-column SELECT privilege, so we're already behind
> the curve here. The main problem again is to figure out a reasonable
> means for the executor to know which columns to check. TargetEntry
> markings won't help here. I thought about adding a bitmap to each
> RTE showing the attribute numbers explicitly referenced in the query,
> but I'm unsure if that's a good solution or not.
>
> I'd be willing to leave this as work to be done later, since 90% of
> the patch is just concerned with the mechanics of storing per-column
> privileges and doesn't care which ones they are exactly. But it
> needs to be on the to-do list.
I think it would be quite unfortunate to not include per-column SELECT
privileges with the initial version. It has significant uses and would
really be a pretty obvious hole in our implementation.
> What I think would be a more desirable solution is that the table ACL
> still sets the table-level INSERT or UPDATE privilege bit as long as
> you have any such privilege. In the normal case where no per-column
> privilege has been granted, the per-column attacl fields all remain
> NULL and that's all you need. As soon as any per-column GRANT or
> REVOKE is issued against a table, expand out the per-column ACLs to
> match the previous table-level state, and then apply the per-column
> changes. I think you'd need an additional pg_class flag column,
> say "relhascolacls", to denote whether this has been done --- then
> privilege checking would know it only needs to look at the column
> ACLs when this field is set.
I agree with this approach and feel it's alot cleaner as well as faster.
We definitely don't want to make permission checking take any more time
than it absolutely has to.
> With this scheme we don't need per-column entries in pg_shdepend,
> we can just reference the table-level bits as before. REVOKE would have
> the responsibility of getting rid of per-column entries, if any, as a
> followup to revoking per-table entries during a DROP USER operation.
Doesn't sound too bad.
> Something else that needs to be thought about is whether system columns
> have privileges or not. The patch seems to be assuming "not" in some
> places, but at least for SELECT it seems like this might be sensible.
> Also, you can already do COPY TO the OID column if any, so even without
> any future extensions it seems like we've got the issue in front of us.
I certainly feel we should be able to have per-column privileges on
system columns, though we should only use them were appropriate, of
course.
> One other mistake I noted was that the version checks added in pg_dump
> and psql are ">= 80300", which of course is obsolete now.
That one's pretty easy to handle. :)
Thanks,
Stephen
Attachment
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> I'm not sure where we go from here. Your GSOC student has disappeared,
>> right? Is anyone else willing to take up the patch and work on it?
> I'm willing to take it up and work on it.
Excellent! As you say, you've seen that code before, so it should
go more quickly for you than most people.
>> One possible solution is to add a flag field
>> to TargetEntry to carry the information forward.
> I'll look into this, I liked the bitmap idea, personally.
Yeah, I do too. What I am thinking now is that we need two bitmaps
per RTE: one showing the columns explicitly referenced (hence needing
SELECT permission) and one showing the columns assigned to (hence
needing INSERT or UPDATE as appropriate --- we will never have both
cases in one Query, so we don't need two bitmaps). It would be
fairly easy to build these in the parser, and to check them in
the executor ... the fun part would be keeping them up-to-date
while the rewriter and planner mash the query around ...
>> One other mistake I noted was that the version checks added in pg_dump
>> and psql are ">= 80300", which of course is obsolete now.
> That one's pretty easy to handle. :)
Yeah, I just wanted to make sure it wasn't forgotten. It's the kind
of thing you'd not notice in testing unless you thought to try pg_dump
against old server versions (which is a good idea of course).
regards, tom lane
Tom Lane wrote: > > I'm not sure where we go from here. Your GSOC student has disappeared, > right? Is anyone else willing to take up the patch and work on it? > > > No, he has not disappeared at all. He is going to work on fixing issues and getting the work up to SQL99 level. Your review should help enormously. Stephen, perhaps you would like to work with him. cheers andrew
Am Mittwoch, 7. Mai 2008 schrieb Tom Lane: > >> 1.1 Add a column named 'attrel' in pg_attribute catalog to store > >> column privileges. Now all column privileges are stored, no matter > >> whether they could be implied from table-level privilege. > > What this actually means, but doesn't say, is that there's no > table-level representation of INSERT/UPDATE privilege any more at all. > I think this is a pretty fundamental design error. In the first place > it bloats pg_attribute with data that's entirely redundant for the > "typical" case where per-column privileges aren't used. In the > second place it slows privilege checking for the typical case, since > instead of one check for the relation you have to do one for each > attribute. There are some other problems too, like having to extend > pg_shdepend to include an objsubid column, and some other places where > the patch has to do awkward things because it's now lacking table-level > information about privilege checks. I haven't read the patch, but there is also a semantic issue, namely what happens to columns added after the grant. If the GRANT was to the table, new columns should get the same privileges.
* Andrew Dunstan (andrew@dunslane.net) wrote:
> Tom Lane wrote:
>> I'm not sure where we go from here. Your GSOC student has disappeared,
>> right? Is anyone else willing to take up the patch and work on it?
>
> No, he has not disappeared at all. He is going to work on fixing issues
> and getting the work up to SQL99 level.
Great!
> Your review should help enormously.
>
> Stephen, perhaps you would like to work with him.
I'd be happy to.
Thanks,
Stephen