Re: security label support, part.2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: security label support, part.2
Date
Msg-id AANLkTim60Qa+FEPC_qLwg26K9si9Z2Tgf9C-693FmQRi@mail.gmail.com
Whole thread Raw
In response to Re: security label support, part.2  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
2010/8/18 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> It's also worth pointing out that the hook in ExecCheckRTPerms() does
>> not presuppose label-based security.  It could be used to implement
>> some other policy altogether, which only strengthens the argument that
>> we can't know how the user of the hook wants to handle these cases.
>>
> If rte->requiredPerms would not be cleared, the user of the hook will
> be able to check access rights on the child tables, as they like.
> How about an idea to add a new flag in RangeTblEntry which shows where
> the RangeTblEntry came from, instead of clearing requiredPerms?
> If the flag is true, I think ExecCheckRTEPerms() can simply skip checks
> on the child tables.

Something along those lines might work, although I haven't yet
scrutinized the code well enough to have a real clear opinion on what
the best way of dealing with this is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: GROUPING SETS revisited
Next
From: Pavel Stehule
Date:
Subject: proposal: tuplestore, tuplesort aggregate functions