Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
 >   2) Do we want row-level permissions at the SQL level?

Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
However, the scale of its demand is unclear for me.
Yes, which is why I would like the community to answer the question
before you have to start coding things.  I will say that if we do want
it, the SE-Linux code will be 96% in separate modules and will make it
much easier to accept.
OK, I'll stop my hand today, and wait for pgsql-hacker's opinions.

Here is how I think SQL-level row permissions would work:

We already have an optional OID system column that can be specified
during table creation (WITH OIDS).  We could have another optional oid
column (WITH ROW SECURITY) called security_context which would store the
oid of the role that can see the row;  if the oid is zero (InvalidOid),
anyone can see it.  SE-PostgreSQL would default to WITH ROW SECURITY and
use the oid to look up strings in pg_security.

The above explanation is not correct, as Tom mentioned.
The security system column is declared as TEXT type, however, every tuple
has a Oid value to indicate pg_security system catalog. It enables to
prevent waste of storage. When user tries to read the system column,
it is translated from Oid to text representation.

If the oid is zero, SE-PostgreSQL requires SELinux to provide an alternative
security context called as "unlabeled_t". And SE-PostgreSQL checks client's
right for the tuple which is considered as "unlabeled_t".

The part of implementation is specific for SE-PostgreSQL, so another security
mechanism will able to handle InvalidOid as a mark of "no specific checks".

Is this something we want for non-SE-PostgreSQL builds? SE-PostgreSQL
would still be a compile-time option because of all the additional
SE-Linux support code.

The new system column is now enabled only for SE-PostgreSQL builds.
When we don't enables it, the system column is not appeared and it
does not reuire any additional field in HeapTupleHeader.

We provide it as a common facility for "enhanced" security mechanism.
If the guest of PGACE need the security system column, it has to
define "SECURITY_SYSATTR_NAME" in pg_config.h via configure script.
This constant is the key to activate the security system attribute.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to