Greg Smith wrote:
> KaiGai Kohei wrote:
>> In the v8.4 development cycle, I got a suggestion to reduce
>> a burden of reviewer to split off a few functionalities, such
>> as "security_context" system column and row-level access controls.
>>
> I lost track of this patch and related bits somewhere along the way, had
> to triage my unread mail a few times. Could someone summarize how it now
> fits into plans for more general row-level access controls in the
> database? I know incompatibilities between the SEPosgreSQL model for row
> filtering and thoughts for a more general permissions feature that did
> something similar were a major design issue in the early 8.4 versions of
> SEPostgreSQL, and that as you say you've been working on that. I'm not
> sure what relationship there is between those two today though, or
> exactly where the general non-SELinux row filtering is at on the roadmap.
At least, I don't have a plan to submit a patch for row-level access
controls in the v8.5 development cycle. We should focus on the "lite"
version here.
On that basis, I shall propose the row-level access controls after
the current efforts getting closed.
I found a uncertain term in your comment.
It seems to me the "model" has two meanings in this context.
- The way to make access control decision (allowed? or denied?).
- The granularity of access controls (tables? columns? or tuples?).
I think you are saying about the latet point.
In my plan, I'll propose a feature something like Oracle Virtual
Private Database which filters violated rows based on the decision
making function. (e.g tbl.username = getpgusername() )
Needless to say, it is a general non-SELinux feature. But, if we
have such a PG-VPD, it is not difficult to implement a decision
making function based on SELinux.
Is it correct for the answer?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
