On Wed, Dec 18, 2013 at 10:21 PM, Craig Ringer wrote:
> My main worry was that it requires the user to build everything
> manually, and is potentially error prone as a result. To address that we
> can build convenience features (label security, ACL types and operators,
> etc) on top of the same in
On 12/18/13 10:21 PM, Craig Ringer wrote:
In the end, sometimes I guess there's no replacement for "WHERE
call_some_procedure()"
That's where I keep ending up at. The next round of examples I'm
reviewing this week plug pl/pgsql code into that model. And the one
after that actually reference
On 12/18/2013 11:14 PM, Robert Haas wrote:
> To be clear, I wasn't advocating for a declarative approach; I think
> predicates are fine. There are usability issues to worry about either
> way, and my concern is that we address those. A declarative approach
> would certainly be valuable in that,
On Wed, Dec 18, 2013 at 3:30 AM, Craig Ringer wrote:
> In my view the proposed patch doesn't offer a significant improvement in
> declarative security, beyond what we can get by just adding update
> support to s.b. views and using search_path to control whether a user
> sees the view or the base t
On Tue, Dec 17, 2013 at 1:27 PM, Simon Riggs wrote:
> Not sure I'd say required, but its certainly desirable to have
> updateable security barrier views in themselves. And it comes across
> to me as a cleaner and potentially more performant way of doing the
> security checks for RLS.
Yes, that's
On 12/18/2013 02:21 AM, Simon Riggs wrote:
> On 16 December 2013 14:36, Craig Ringer wrote:
>
>> - Decide on and implement a structure for row-security functionality its
>> self. I'm persuaded by Robert's comments here, that whatever we expose
>> must be significantly more usable than a DIY on to
On 12/18/2013 01:03 AM, Robert Haas wrote:
> On Mon, Dec 16, 2013 at 3:12 PM, Gregory Smith
> wrote:
>> > On 12/16/13 9:36 AM, Craig Ringer wrote:
>>> >>
>>> >> - Finish and commit updatable security barrier views. I've still got a
>>> >> lot of straightening out to do there.
>> >
>> > I don't fo
On 17 December 2013 17:03, Robert Haas wrote:
> On Mon, Dec 16, 2013 at 3:12 PM, Gregory Smith
> wrote:
>> On 12/16/13 9:36 AM, Craig Ringer wrote:
>>>
>>> - Finish and commit updatable security barrier views. I've still got a
>>> lot of straightening out to do there.
>>
>> I don't follow why yo
On 16 December 2013 14:36, Craig Ringer wrote:
> - Decide on and implement a structure for row-security functionality its
> self. I'm persuaded by Robert's comments here, that whatever we expose
> must be significantly more usable than a DIY on top of views (with the
> fix for updatable security
On Mon, Dec 16, 2013 at 3:12 PM, Gregory Smith wrote:
> On 12/16/13 9:36 AM, Craig Ringer wrote:
>>
>> - Finish and commit updatable security barrier views. I've still got a
>> lot of straightening out to do there.
>
> I don't follow why you've put this part first. It has a lot of new
> developme
On 12/16/13 9:36 AM, Craig Ringer wrote:
- Finish and commit updatable security barrier views. I've still got a
lot of straightening out to do there.
I don't follow why you've put this part first. It has a lot of new
development and the risks that go along with that, but the POC projects
I've
On 12/16/2013 10:43 PM, Tom Lane wrote:
> Craig Ringer writes:
>> - Add an attribute to portals that stores the user ID at the time the
>> portal was planned. Possibly extensibly; I'd be surprised if we won't
>> need to associate other local info with a portal later.
>
> This bit seems rather con
Craig Ringer writes:
> - Add an attribute to portals that stores the user ID at the time the
> portal was planned. Possibly extensibly; I'd be surprised if we won't
> need to associate other local info with a portal later.
This bit seems rather confused. A portal is a runnable query; we
do not s
Hi all
I'd like to outline a path toward getting row-security into core.
Comments / discussion appreciated.
I think I/we need to:
- Finish and commit updatable security barrier views. I've still got a
lot of straightening out to do there.
- Add an attribute to portals that stores the user ID at
14 matches
Mail list logo
