Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

KaiGai Kohei wrote:
> > But your larger point is that SQL-row-level security should always be
> > available, which I just posted about.
> 
> If so, it should be hardcoded on somewhere, no need to be implemented
> as a guest of PGACE security framework. Its purpose is to implement
> enhanced security mechanisms with minimum impact to core facilities.
> 
> If you intend to implement is as a hardcoded feature, I can agree.
> Please wait for a few days, I'll try to implement it.
> So, ignore the 6th patch during the days and make progress to review
> the rest of patches.

Hold, please don't code yet.  You might have already read our
developer's FAQ:
http://wiki.postgresql.org/wiki/Developer_FAQ#What_do_I_do_after_choosing_an_item_to_work_on.3F

but I feel we need to follow part of it to prevent you from repeatedly
having to adjust your patch, which I think has happened in the past.

Let's decide exactly what configure options, GUC options, system catalog
changes, and user-visible SQL command syntax we are going to use for the
patch before you recode anything.

For example, what configure flags are we going to have?  I assume just
'--enable-selinux', right?

Second, system catalogs; are you going to have separate columns for
SQL-level row security and SE-Linux security?  If so, is the SE-Linux
column only going to be created by the --enable-selinux build?  If so,
that is going to mean that the /data directory is going to be affected
by the --enable-selinux flag, which is not ideal --- it would be good if
someone could switch to an SE-Linux binary without to dump/reload.  One
nice idea would be to have one "security" column and allow both
SQL-level and SE-Linux security values to be stored in the column,
perhaps at the same time;  that way there is no new column needed for
SE-Linux.

I know I suggested the security column act like the system oid column,
but now I am thinking I was wrong.  The system oid column stores an
auto-generated value so it was necessary to have it be specified at
CREATE TABLE time because it is guaranteed to take storage space.  For
the security column, in most cases it will be null, meaning it would not
take any storage space becuase we use a null bitmap for null column
values.  So, perhaps the security column should be in every table and we
can just make it default to null;  I think that would give us much more
flexibility to add security to existing tables.

Finally, I am wondering what other things should be adjusted that I have
not thought of yet.  I would like to make KaiGai's job as easy as
possible.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +