Robert Haas wrote:
> On Thu, Dec 10, 2009 at 11:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If you're not prepared to assume that we're going to do row level
>> security, it's not apparent why we should be embarking on this course
>> at all. And if you do assume that, I strongly believe that my effort
>> estimate above is on the optimistic side.
>
> Row-level security is going to be a very difficult project, no
> question about it.
Yes, I also agree it is a reasonable decision to separate row-level
from the initial proposition.
> However, if we implement a general facility rather
> than something SE-Linux specific, I think we will have a killer
> feature. I realize it's not for everyone, but for those who need it,
> it's kick-ass.
>
> But we have a while before we get to the point where we can even start
> worrying about that pain. Stephen Frost's statements about the way
> our access controls are scattered throughout our code are, I think, on
> target. And cleaning that up seems to me to have value independently
> of SE-PostgreSQL. I'm feeling (right now, anyway) like it would make
> sense to pursue further the patch that KaiGai submitted for the last
> CF and you rejected. It needed work, but I don't think it was
> hopeless, or valueless.
Here is a few issues to salvage the access control reworks patch.
It tried to provide a set of common entry points both of the default PG
security model and SELinux (and upcoming ones).
However, the default PG model does not have same origin with label-based
mandatory access controls, such as SELinux, from a historical angle.
So, this reworks needed many of unobvious changes to the core routines.
("core routines" means code except for enhanced security features.)
It tried to provide a set of comprehensive entry points to replace existing
PG checks at once.
However, the SE-PgSQL/Lite patch covers accesses on only database, schema,
tables and columns. Is it necessary to be comprehensive from the beginning?
It might be too aggressive changes at once.
Frankly, I hesitate to salvage the patch once rejected, as is.
If we implement a set of security hooks, It seems to me the following approach
is reasonable:
* It does not touch the existing PG default checks. The purpose of security hooks are to host "enhanced" security
features.
* It does not deploy hooks on which no security provider is now proposed. It is important to reduce unnecessary
changeset.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
