Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

KaiGai,

* KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
> Stephen Frost wrote:
> > I think Bruce's question was where you stored the security_acl and
> > security_label columns.  Based on your response (and a bit of purusal
> > through the code.google site), it looks like you still have security_acl
> > and security_label defined as internal columns and being included
> > for at least system tables (or is it everywhere?).
>
> In the current working tree, it (security id) is stored within
> padding field of HeapTupleHeader, so internal facility can read
> it via HeapTupleGetSecLabel(), but I already removed "security_acl"
> and "security_label" definition.
> Its basic structure is unchanged, the text form of security label
> is stored within pg_security system catalog.

I'm pretty sure that structure is part of what people were unhappy about
though, and what makes it a much more invasive change that violates
certain levels in the system by requiring information at much lower
levels than it had before.

> > I think what people
> > are looking for, instead, is either additional columns to just the
> > existing system tables that need them (eg: pg_class, pg_attribute) or
> > included in the existing ACL structure (the aclitem structure).  Another
> > option might be a seperate set of tables.
>
> It should not be held in text form within each tuples.
> Please remind why I rework for the feature again.
> Its facilities are a bit large to get included at a time,
> so its development should be done step-by-step approach and
> separatable ones (row-level, largeobjects) are postponed.
> This change is extreamly large, almost same as implementing
> from zero. I think it is far from step-by-step.

Yes, the development should be step-by-step, with minimally invasive
changes each time.  The first step is just hooking into SELinux for
access levels that PostgreSQL already supports (database, schema,
table, column).  Requiring that the HeapTupleHeader be changed and that
additional internal system columns be added, along with SELinux checks
at levels that aren't appropriate, is alot more than this first patch
should really need.  Those kinds of changes would be with the patch to
add non-SELinux row-level security.  Following that, SELinux hooks would
be added to the RLS checks.

I think you need to look at it from the point of view of the committers
and consider the whole patch, not just the quantity of code under
security/.  While that is important, the changes to the code *outside*
of security/ is what the committers are going to be most concerned about
because that gets into the overall structure and design and are areas
which are much more likely to affect users who don't use this feature,
performance, etc.

Or at least, that's what I'd expect.  Getting some commentary from core
would be nice..
Thanks,
    Stephen