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

KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> 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.
> > 
> > Sorry, I am confusing system columns, like pg_class.relname, with
> > user-table system columns, like mytable.xmin.  I don't think we have the
> > ability of having user-table system columns nullable, right?
> 
> Currently, it assumes system columns should not be NULL.
> heap_getsysattr() always set the given 'isnull' 'false'.

Yep, that is a problem.

> > We do have a per-row HEAP_HASOID bit, so I wonder if we can have a
> > HEAP_HASSEC bit too.  Right now the HEAP_HASOID is controlled by the
> > CREATE/ALTER table;
> 
> The current patch add HEAP_HASSECURITY bit to t_infomask. :-)
> When it is false, its security field is not available and not allocated.

Good.

>  > I am unclear how hard it would be to allow it to be
>  > controlled via INSERT, meaning it would be present only if the row had a
>  > SEC value supplied.
> 
> It is impossible, and not suitable for SE-PostgreSQL.
> The HeapTuple is allocated prior to fetch INSERT'ed value.
> In addition, SE-PostgreSQL assigns its default security context when no
> security attribute is given.

When SE-Linux is enabled, couldn't NULL represent the default security
context?

> > Here is our OID column on some rows but not others:
> > 
> >     test=> CREATE TABLE test (x INT) WITH oids;
> >     CREATE TABLE
> >     test=> INSERT INTO test VALUES (1);
> >     INSERT 16392 1
> >     test=> ALTER TABLE test SET WITHOUT OIDS;
> >     ALTER TABLE
> >     test=> INSERT INTO test VALUES(2);
> >     INSERT 0 1
> >     test=> SELECT oid, * FROM test;
> >     ERROR:  COLUMN "oid" does not exist
> >     LINE 1: SELECT oid, * FROM test;
> > 
> > but it has per-table granularity;  the oid value for '1' is still
> > stored, but is no longer visible;  that would not work for the security
> > value.
> 
> If we can control the Row-level ACLs via table options, what should be
> happen when we turn off the feature?
> IMO, it is natural to ignore Row-level ACLs independent from whether
> the stored tuple actually has ACLs, or not.

Hmmm, sounds like perhaps a GUC is needed there.

> > The complexity is that the column would always exist (unlike OID), but
> > would be NULL if not assigned to.  This would allow any table to have
> > security by default, and have no overhead if security is not defined for
> > the row.  Now, I realize SE-Linux would have security defined for each
> > row, but SQL-level row security might not, and this would allow the
> > feature to be very useful, perhaps with a GUC that required security for
> > SE-Linux, and /data would be the same for SE-Linux and non-SE-Linux.  If
> > we could make the row behave like this we might use separate columns for
> > SQL-level and SE-Linux security because there would be no storage
> > overhead unless security was used.
> 
> I basically agree for the idea of separate columns.
> My preference is "acl column" as general column (not a system column)
> which is defined at limited number of tables with ROW_LEVEL_ACL=ON.

That would certainly be the easiest approach.

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