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

From Robert Haas
Subject Re: security label support, part.2
Date
Msg-id AANLkTimZ0rCJJz32cY1kmHmccBPb6MbojyaJ6Up1qzKR@mail.gmail.com
Whole thread Raw
In response to Re: security label support, part.2  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: security label support, part.2
Re: security label support, part.2
List pgsql-hackers
2010/7/23 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> Hmm.  How about if there's just one provider loaded, you can omit it,
>> but if you fail to specify it and there's>1 loaded, we just throw an
>> error saying you didn't specify whose label it is.
>>
> Perhaps, we need to return the caller a state whether one provider checked
> the given label at least, or not.

Return to the caller?  This is an SQL command.  You either get an
error, or you don't.

> If it was omitted, all the providers try to check the given label, but it
> has mutually different format, so one of providers will raise an error at
> least.

Yeah, but it won't be a very clear error, and what if you have, say, a
provider that allows arbitrary strings as labels?  Since this is a
security feature, I think it's a pretty bad idea to allow the user to
do anything that might be ambiguous.

> It means we have to specify the provider when two or more providers are
> loaded, but not necessary when just one provider.

But that should be fine.  Loading multiple providers should, as you
say, be fairly rare.

>>>> I think it is 100% clear that row-level security will require
>>>> completely separate infrastructure, and therefore I'm not even a tiny
>>>> bit worried about this.  :-)
>>>>
>>> Hmm. Are you saying we may degrade the feature when we switch to the
>>> completely separate infrastructure? Is it preferable??
>>
>> Uh... no, not really.  I'm saying that I don't think we're backing
>> ourselves into a corner.  What makes you think we are?
>>
> Sorry, meaning of the last question was unclear for me.... Is it a idiom?

I don't understand why we wouldn't be able to support multiple
providers for row-level security.  Why do you think that's a problem?

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patch for 9.1: initdb -C option
Next
From: Stephen Frost
Date:
Subject: Re: security label support, part.2