Bruce Momjian wrote:
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.
Just as an FYI, SELinux does this in general. There is an access vector cache in
the kernel that caches the access computations, and there is also a userspace
implementation in libselinux that most apps use. KaiGai reimplemented the AVC
because he wanted it to work in a shm and be shared by multiple postgres processes.
There is also a sidtab which is just a hashtable that maps string contexts to
sids. The sidtab is filled at runtime and not persistent across boots, which
means the contexts are generally stored as text on the persistent medium (like
the xattr's on the filesystem).
It doesn't matter from a security perspective whether the contexts are stored as
strings or sids, its just an optimization you guys need to work out.
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.
I may not be understanding this but I don't see why. In SELinux everything is an
object, and all objects have contexts. No access is specified on the object or
in the context, that is all done in the policy currently loaded in the security
server. system tables and user tables shouldn't be treated differently
implementation wise, they should just have a context and defer the decision
making to the policy.
In practice the system tables (and rows within the tables) would have a context
that restricts access tightly, but this is up to the policy, not the implementation.
FYI, it is possible we might implement row-level security a different
way in 8.5.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
