Re: SE-PostgreSQL and row level security - Mailing list pgsql-hackers

BogDan Vatra wrote:
>> On Fri, Feb 13, 2009 at 02:29:39PM +0200, BogDan Vatra wrote:
>>> [..]
>>>>> A message for postgresql decision board:
>>>>>
>>>>> Dear postgresql hackers, if I can do something to push row level
>>>>> acl for 8.4 please tell me, I do anything to have this feature,
>>>>> it will help me, and I hope many others, this feature will help
>>>>> to develop client to postgres applications without a server
>>>>> application or tones of triggers and viewers.
>>>> I can understand your pains and you want the row-level security
>>>> stuffs to be merged within the vanilla v8.4. However, I would like
>>>> you to understand we don't have infinite time to review proposed
>>>> features for the upcoming v8.4.
>>> I don't want to be to selfish , but AFAIK postgresql is already
>>> delayed (according to PostgreSQL_8.4_Development_Plan page
>>> "http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan"
>>> beta1 should be out on 1st January 2009), so, what's matter another
>>> 2-3 weeks of delay?  Or, maybe, I'm the only one who consider this a
>>> *must to have* feature.
>> You probably aren't the *only* one, but row-level ACL has unsolved
>> math problems in it, which means it's a no go for 8.4.
>>
> 
> I'm glad to see I'm not the only one who need row-level ACL, I was think
> I'm only a dreamer. I didn't know row-level ACL has math problems in it,
> please, can you give me more details ?

At the previous discussion, two items were pointed out.

The one is called as covert channel. When a tuple with PK is refered by
one or more tuples with FK, row-level control prevents to update or delete
the PK, even if the FK is invisible from users. It allows users to infer
existence of invisible FK. However, our evaluation criteria (ISO15408, CC)
does not consider it as a problem. The requirements for security feature
depends on its purpose and environments in use. The purpose of SE-PostgreSQL
is to improve security in general enterprise class systems, such as other
commercial databases (Oracle Label Security. etc...). In this class, we
don't need to eliminate the covert channel. What we should do here is to
provide an explicit documentation about this behavior to help user's decision.

The other is an interaction with optimization. The row-level security
works as if an additional condition is automatically appended to the target
relations. The current optimizer works without consideration for row-level
security, so it can make undesirable optimization. For example, upcoming
join-removal stuff assumes here is a FK tuple at least, when we do outer
join between two relations with FK constraints. In this case, we can replace
the outer join by inner one with performance gain. However, row-level security
can filter out invisible FK tuples from users. So, it is necessary to provide
a hint to restain such kind of optimization on the relations with row-level
security.

However, these two items are not essentials here.
In the previous discussion, I was pointed out that a single large patch
is hard to review for commiters, so we should separate a fullset feature
into several parts and to be reviewed step-by-step.
One other fact is we don't have infinite time to the upcoming v8.4.
Thus, I accepted to separate a few features for getting it merged at v8.4
even if it does not have fullset facilities.

>> Any resources you could commit to getting those problems solved for
>> 8.5 would be awesome, but no amount of whining for a back-port will
>> help you or the project, and frankly, resources committed to a
>> back-port will pretty much stall any attempt to get it into 8.5.
>>
>> What kinds of resources can you dedicate to the solvable problems, and
>> when can you start mobilizing them?
>>
> 
> What I can do ?
> -I can test it in real applications.
> -I'll try to fix math problems.
> -I can even try to code. For this I need more help with postgresql internals.
> -I can donate or sponsor someone else to do things I can't do or things
> what are beyond me.
> When can start this? If I find what are the math problems and KaiGai Kohei
> can give me *only* the row level ACL patch I'll start to work on it even
> tomorrow.

Currently we are waiting for comitter's review.

On the other hand, I also begain to prepare to submit patches for rest of
features at the next development phase, after the first features get merged.

* CVS HEAD + security label/acl management stuff  http://code.google.com/p/sepgsql/source/browse/trunk/sysatt
* trunk/sysatt + row-level security stuff  http://code.google.com/p/sepgsql/source/browse/trunk/rowlv

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>