Re: Adding support for SE-Linux security - Mailing list pgsql-hackers

On Fri, Dec 11, 2009 at 5:36 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > Does that help clarify my example case?
>>
>> That case doesn't seem terribly problematic to me.  It seems clear
>> that we'll want to pass some information about both x and y.  What is
>> less clear is exactly what the argument types will be, and the right
>> answer probably depends somewhat on the structure of the existing
>> code, which I have not looked at.
>
> Allow me to assist- y is never in a structure once you're out of the
> parser:

Well this is why you're writing the patch and not me.  :-)

> ATExecChangeOwner(Oid relationOid, Oid newOwnerId, bool recursing)
>
> I expect you'll find this is more the rule than the exception to alot of
> the existing PG security model, because much of it's responsibility is
> in what I'll call the DDL (under commands/) aspects.  The DML pieces
> (under the executor) are a bit better about this, specifically you could
> pass in a RangeTblEntry, exactly how ExecCheckRTEPerms handles it.
>
> Actually, in a fit of barely-contained mirth, it strikes me that PG
> really has already done what you're suggesting for the 'hard' part- and
> the RangeTblEntry plus ExecCheckRTEPerms is exactly it.  It's all the
> *other* checks we do for the PG security model, under commands/, that
> are the problem here.  The parts of the code that, to be honest, I think
> all us database geeks have historically cared alot less about.

Hmm, interesting.

>> What I'm more concerned about is if
>> the access control decision in this case were based on u for PG DAC, v
>> for SE-PostgreSQL, and w for Robert Haas's Personal Defensive System.
>> If that's the case, and our function signature looks like (x,y,u,v,w),
>> the we should worry.
>
> Right, I understand that.  What I offer in reply is that we focus our
> attention on using the OID+SubOID approach, as I'm suggesting, to the
> fullest extent possible through that mechanism, and appreciate that the
> other arguments passed to the function are derived specifically from the
> parser and therefore unlikely to be changed until and unless we change
> the base syntax of the command and calling function, at which time we
> may have to add arguments to the function signature.  This would
> continue at least until we get to the point where we decide that the
> caller needs to be changed because it's got a huge function sig, and
> move it to something like the structure of the executor and the
> equivilant of ExecCheckRTEPerms() would get updated along with it, at
> that time.

What exactly do you mean by a SubOID?  I'm not really following that part.

...Robert