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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
