On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley
<dpquigl@tycho.nsa.gov> wrote:
> On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
>> 2009/12/11 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> > It tried to provide a set of comprehensive entry points to replace existing
>> > PG checks at once.
>> > However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
>> > tables and columns. Is it necessary to be comprehensive from the beginning?
>> > It might be too aggressive changes at once.
>> >
>> > Frankly, I hesitate to salvage the patch once rejected, as is.
>> >
>> > If we implement a set of security hooks, It seems to me the following approach
>> > is reasonable:
>> >
>> > * It does not touch the existing PG default checks.
>> > The purpose of security hooks are to host "enhanced" security features.
>> >
>> > * It does not deploy hooks on which no security provider is now proposed.
>> > It is important to reduce unnecessary changeset.
>>
>> I think that we should try to move the PG default checks inside the
>> hook functions. If we can't do that cleanly, it's a good sign that
>> the hook functions are not correctly placed to enforce arbitrary
>> security policy. Furthermore, it defeats what I think would be a good
>> side goal here, which is to better modularize the existing code.
>
> So from the meeting on Wednesday I got the impression that Steve already
> did this. However it was rejected because too much information was need
> to be passed around.
I am not sure who "Steve" is or which patch you're talking about, but
suffice it to say that I think the problem you are articulating here
is exactly the one we need to get out from under. I don't know how to
do that yet and...
> They may have been said before but what exactly are the design issues?
...that's the design issue I think we need to surmount. I think it
will be easier to talk through that with a mini-patch that only
affects one object type.
I'll stop here because I see that Stephen Frost has just sent an
insightful email on this topic as well. Hmm, maybe that's the Steve
you were referring to.
...Robert