KaiGai Kohei wrote:
> > Why an OID? We store acl items now without a lookup table; I think
> > there will be at most the same number of SE-Linux entries. Also, by
> > using text we avoid the problem of cleaning out unreferenced pg_security
> > rows, improve performance (no lookups), and simplify the code.
>
> The reason why I concern about text formed security context is
> it has variable length, so it requires to deform/form a HeapTuple
> again when SE-PostgreSQL assigns a default security context.
> If a user inserts a new tuple into pg_xxxx without explicit security
> context, it has to be labeled based on security context. We cannot
> estimate what string will be given prior to ExecInsert(), it needs
> to put a security label on the given HeapTuple.
> If is is a fixed length variable (like "oid"), it is not necessary
> to deform/form them. So, I prefer the security identifier.
>
> In addition, it also has performance gain.
> The current architecture does not need to look up pg_security in most
> cases. SE-PostgreSQL caches results of access controls in userspace
> to reduce the number of kernel invocation.
> (In generally, context switch is a heavy one.)
> All cached entries are tagged by its security identifier, so we can
> lookup the entry without string comparing. The text form is used
> only when it could not find the entry on the cache. In this case,
> SE-PostgreSQL translate security identifier into text form and
> ask for in-kernel SELinux. It requires a text form due to the
> protocol.
That is an interesting optimization I had not thought of.
> At least, we cannot apply this scheme on the next phase (row-level)
> due to the storage consumption and others. So, I don't think it is
> a preferable way to design the first step without ignoring upcoming
> expandability.
The big problem is that the security value on system tables controls the
_object_ represented by the row, while on user tables the security value
represents access to the row. That is just an odd design, and why a
regular system table security value makes sense, independent of the
row-level security feature.
FYI, it is possible we might implement row-level security a different
way in 8.5.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +