Re: New patch for Column-level privileges - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: New patch for Column-level privileges
Date
Msg-id 496C2DAB.8000608@ak.jp.nec.com
Whole thread Raw
In response to Re: New patch for Column-level privileges  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New patch for Column-level privileges
List pgsql-hackers
Tom Lane wrote:
> I'm thinking make_var is not the place to do this.  The places that are
> supposed to be taking care of permissions are the ones that do this:
> 
>         /* Require read access --- see comments in setTargetTable() */
>         rte->requiredPerms |= ACL_SELECT;

Indeed, it seems to me appropriate policy, because CLP feature is
a part of SQL standard access control model.


The rte->requiredPerms is set on the following places:

(1) transformLockingClause() and markQueryForLocking()
It adds ACL_SELECT_FOR_UPDATE for listed relations.
In this case, column-level priv feature checks ACL_UPDATE for each
columns on rte->cols_sel, doesn't it?
So, I think it is unnecessary to care about anything here.

(2) setTargetTable()
It is invoked from transformInsertStmt(), transformUpdateStmt() and
transformDeleteStmt(). I thnk it is a proper place to set rte->cols_mod,
but the caller does not initialize Query->targetList yet, when it is
invoked.
So, I think we need put a function call to set cols_mod on caller side
based on Query->resultRelation and Query->targetList.

(3) scanRTEForColumn()
Stephen's original one patched here, but it does not handle RTE_JOIN
well, so it made a matter on table-joins.
Please revert a code to mark rte->cols_sel, with proper handling for
RTE_JOIN cases.

(4) addRangeTableEntry()
Purpose of the function is to translate RangeVar node to RangeTblEntry
node listed on FROM clause and so on.
I think we don't need to add any column references here.
When the translated relation used for column-references, it is a case
that rte->cols_sel is empty.

(5) addRangeTableEntryForRelation()
It is similar to addRangeTableEntry().
I think we don't need to add something here.

(6) ExpandColumnRefStar() and ExpandAllTables()
They invoke expandRelAttrs() to handle "SELECT * FROM t;" case.
I think here is a proper point to mark refered columns.
Please note that here is no guarantee that given RangeTblEntry has
RTE_RELATION.

Thus, we need the following reworking in my opinion.
(a) Implement a function to set rte->cols_sel and rte->cols_mod correctly,   even if the given rte has RTE_JOIN.
(b) Put a function to set rte->cols_mod on the caller of setTargetTable().
(c) Put a function to set rte->cols_sel on scanRTEForColumn(), expandRelAttrs()   and transformWholeRowRef().

> It's possible that we've missed some --- in particular, right at the
> moment I am not sure that whole-row Vars are handled properly.

Is transformWholeRowRef() a proper place to handle it?
If given RangeTblEntry has RTE_JOIN, it has to resolve it and set
its source's cols_sel.

> And maybe we could refactor a little bit to save some code.
> But those are basically the same places that ought to be adding
> bits to the column bitmaps.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: "Koichi Suzuki"
Date:
Subject: Re: Documenting pglesslog
Next
From: KaiGai Kohei
Date:
Subject: Updates of SE-PostgreSQL 8.4devel patches (r1403)