SEO

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIIPrwrzgMPqB3kigRAvkLAJ9lEaUP/+zM0REFC55UYY/r/qrj1wCfe+Qm
XxdhveJCPt0+Fxl74pq4KPg=
=9j/Q
-----END PGP SIGNATURE-----

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

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

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

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.

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

* 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIIZS5rzgMPqB3kigRAkfyAJ9sQgO34lO9LITtnTjBdd kueBc0RQCfVp53
OwCrL0EodAj6X52g1ljk9BY=
=B5bf
-----END PGP SIGNATURE-----