Re: Adding support for SE-Linux security

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost <sfrost(at)snowman(dot)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:

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.

> 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.

Thanks,

Stephen