Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

KaiGai Kohei wrote:
> Heikki Linnakangas wrote:
>> KaiGai Kohei wrote:
>>> Robert Haas wrote:
>>>> 2009/10/27 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>>> - no statement support to specify security context.
>>>>> (It makes impossible to add support in pg_dump. Is it really OK?)
>>>> I doubt that anything without pg_dump support would be even vaguely OK...
>>> In my previous experience, it enabled to reduce 300-400 lines of the patch.
>>> But here is no more sense than the 300-400 lines.
>>>
>>> In my honest, I like to include a feature to specify an explicit security
>>> context in the patch from the begining.
>>> (It also allows to attach test cases with more variations.)
>> Can you explain why that's required for pg_dump support? I was thinking
>> that there would be no explicit security labels on objects, and
>> permissions would be checked based on other inherent properties of the
>> object, like owner, name, schema etc.
>
> In SELinux model, security context is the only property which can be
> used to decision making based on the security policy.
> It never uses any other properties, like owner, name, ...

The security context doesn't necessary need to be given explicitly.
Things like network ports, files in filesystems that don't support
security labels are assigned a security context based on some external
policy.

Hmm, I guess the whole feature becomes completely pointless if all
objects always have their default labels, and can't be changed. So I
guess we need that.

I think this discussion started when I wondered why we can't put the
SE-pgsql check for creating an object (e.g table) into
pg_namespace_aclcheck() without changing the signature. The reason you
gave is that we need the security context of the new table being created
to decide if creating such a table is allowed. But assuming that the new
table inherits the security context of the schema it's created in,
pg_namespace_aclcheck() *does* have all the necessary information: it
knows the namespace which determines the new object's security context.
As long as we don't provide syntax to define the security context in the
CREATE command, we're fine, even if there's an ALTER command to change
the security context of the object after the creation.

I'm not sure how much of a difference that detail makes in the big
scheme of things, I'm just trying to find ways to make the patch
minimally invasive..

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com