Re: [RFC] Security label support

On Thu, May 27, 2010 at 4:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> I'm not real sure that you want a dependency for a security label anyway
>>> --- wouldn't that mean each label could only be used for one object?
>
>> Err, your question comes across to me like "if you added comments to
>> pg_depend, you'd only be able to use a given comment X for one object?".
>> Doesn't make alot of sense. :)
>
> Well, one of us is confused.  I thought the idea was that the same
> security label would apply to many different objects.  If each object
> has its own label, you're going to need an awfully large label cache
> for performance to be sane.

I think this only makes sense when and if we implement row-level
security. The labels for SELinux are, say, 64 byte strings. That's
really not that big, if these are only being applied to objects like
tables, and even columns. More to the point, ISTM a cache would be
fairly useless anyway, because you have to pass the labels themselves
to the OS to get an access control decision, which is also based on
the type of object that you're doing something to and the operation
you're doing to it. It probably make sense to cache the results of
the access-control lookup within a query - for example, if all the
labels of a table you're accessing have the same label, just ask once
for all of them, instead of individually for each one - but I can't
see how you could usefully do much more than that.

Now, if we were talking about row-level security, well, that's a whole
different situation. Now the space to store the individual labels
might become burdensome. But that's a problem for another day,
hopefully a day when I'm out of town.

>> The structure for pg_seclabel we were talking about would be very
>> similar to pg_description, eg:
>
>> CREATE TABLE pg_seclabel (
>>   objoid oid not null,
>>   classoid oid not null,
>>   objsubid integer not null,
>>   label text
>> );
>
>> We could move label into another table (eg: pg_labels) and then give an
>> OID to each label and then store the label's OID in pg_seclabel.
>
> OK, but the notion that you would try to remove "orphan" pg_labels
> entries seems entirely wrongheaded to me.  The labels would be
> long-lived objects.

Now I'm confused. Previously you complained about not having a
garbage collection mechanism for labels - now you seem to be saying
that we should never garbage collect.

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