Re: Updates of SE-PostgreSQL 8.4devel patches - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: Updates of SE-PostgreSQL 8.4devel patches
Date
Msg-id 48DC7358.7000800@ak.jp.nec.com
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Tom Lane wrote:
>>> You mean her data just disappears?  Doesn't sound very reasonable to me.
> 
>> Well, she actually gets an error rather than a query with missing data,
>> which is proabably the best we are going to do, unless we don't
>> implement row-level security at all.
> 
> Quite honestly, I think there is no case at all for implementing
> row-level security given our current state of knowledge.  We have no
> idea how to define it in a way that doesn't leak information.  And *that
> isn't good enough*.

Several prior commercial database management systems give us a hint.

For example, Oracle Label Security can support row-level access
controls, but they does not care such kind of information leaking
called as "covert channel".
It applies an implicit view for row-level access controls, as
I mentioned. (At least, I cannot find a description about PK/FK
constraint in their documentaion with more than 300 pages volume.)

We can think the fact Oracle provides the options shows us there are
unignorable number of people think it is good enough for them.
I think such kind of decision should be made by end-users.
No need to say, I (developer) have to provide well documentation to
shows its specification and *limitation*.
Thus, what Peter said is right. It's also my work.

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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Bug in ILIKE?
Next
From: iihero
Date:
Subject: About the parameter of API: PQprepared