Re: [v9.1] sepgsql - userspace access vector cache - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [v9.1] sepgsql - userspace access vector cache
Date
Msg-id CADyhKSV3=cJ17wK039aGdmXShTYvrCP06oTFJBOnX-gdNMrZ8w@mail.gmail.com
Whole thread Raw
In response to Re: [v9.1] sepgsql - userspace access vector cache  (Yeb Havinga <yebhavinga@gmail.com>)
List pgsql-hackers
2011/7/21 Yeb Havinga <yebhavinga@gmail.com>:
>
>> Is it possible to only include the syscache on --enable-selinux
>> configurations? It would imply physical data incompatibility with standard
>> configurations, but that's also true for e.g. the block size.
>>
>> Also, the tests I did with varying bucket sizes suggested that decreasing
>> the syscache to 256 didn't show a significant performance decrease compared
>> to the 2048 #buckets, for the restorecon test, which hits over 3000 objects
>> with security labels. My guess is that that is a fair middle of the road
>> database schema size. Are you unwilling to pay the startup overhead for a
>> extra 256 syscache?
>>
>
> Hello KaiGai-san,
>
> off-list,
>
Unfortunatelly, not so...

> I was wondering why the catalog pg_seclabel exists at all. Why not store the
> labels together with the objects (pg_class, pg_attribute etc) ? The syscache
> wouldn't be needed in that case.
>
Although current sepgsql support to assign security label on limited number of
object classes (schema, relation, column and functions).
However, we have planed to control accesses on whole of objects managed by
PostgreSQL, not only these four.

If we needed to expand system catalog everytime when an object get newly
supported, the patch would be more invasive and make hard to upstream.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Yeb Havinga
Date:
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Next
From: Tom Lane
Date:
Subject: Re: sinval synchronization considered harmful