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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
