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

KaiGai Kohei wrote:
> >> CREATE TABLE t (
> >> a int,
> >> b text
> >> ) WITH (ROW_LEVEL_ACL=ON);
> >
> > As I mentioned below, this might not be necessary, meaning that row
> > security is enabled for rows where you set the row security value and
> > does not need to be turned on at create table time.
>
> The reason why I proposed the ROW_LEVEL_ACL option is to reduce storage
> consumption for NULL bitmap. For example, the following INSERT originally
> didn't need NULL bitmap, but the "acl column" is implicitly NULL, so the
> HeapTuple has HEAP_HASNULL flag and NULL bitmap is allocated.
>
> INSERT INTO t VALUES (1, 'aaa');
>
> If it is acceptable, I don't think the option is necessary.

I was hoping we could allow the column to be null based only on the
bitmask without having to use the user-column bitmask but maybe that
isn't possible.

> >> As you noticed, a "conditional system column" can be open to discuss.
> >> If someone switch his binary to SE- version, the tables already defined
> >> in $PGDATA don't have "security_context" system column. SE-PostgreSQL
> >> handles tuples stored within the table as "unlabeled" one, but it does
> >> not allow users to access the attribute due to lack of proper system
> >> column.
> >
> > Right, if the "security_context" always exists, but is null, moving to
> > SE-Linux would allow them to add security without dump/reload.
>
> Yes, but it is not recommendable in generally. For meaningful access
> controls, "unlabeled" objects should be labeled properly. :)

We could get tricky and use the proper default when that column is null
for user-visible queries. Again, I am just throwing out ideas.

> >> If it is represented as NULL bitmaps, it requires a tuple has its null bitmaps
> >> which need 4-bytes at least, so it can make additional storage consumption.
> >> Thus, NULL-bitmap approach is not suitable to represent "security column"
> >> because it has to be defined for any tables. But, it can be suitable for
> >> "acl column".
> >
> > Ah, that is a good point, that if we have "security column" which is
> > usually null then we are requiring the NULL bitmask.
> >
> > I was thinking of having them be system columns and therefore only the
> > bitmask would specify if the value exists or not. I am again thinking
> > of having both columns always exist, making your code clearer and more
> > portable for people going to and leaving SE-Postgres.
>
> The HEAP_HASSECURITY flag looks like a specific purpose NULL-bitmap
> which only shows whether the tuple has security value, or not.

Yep, that was my hope.

> >> The following proposal is my idea:
> >>
> >> - The Row-level ACLs is implemented as a hardcoded feature, not a guest of
> >> PGACE security framework.
> >
> > Yep, good.
> >
> >> - It can be enabled/disabled via table options as:
> >> CREATE TABLE t (
> >> a int,
> >> b text
> >> ) WITH (ROW_LEVEL_ACL=ON);
> >
> > Can we make it just always on? See above.
>
> If we assume users set up Row-level ACLs for specific tables, per-table
> option is meaningful for reduction of NULL-bitmap space in the tuple
> without any NULL-values on general columns.

Right. I was hoping there was a way to have HEAP_HASSECACL control if
the value is present or not.

I sure wish others were adding ideas to this discussion.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +