Greg Stark wrote:
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas wrote:
I'm not sure I understand what you mean by that. I expect that if I
deny a particular user access to SELECT from a particular table the
system will throw a permissions error if that user later enters
"SELECT * FROM ". I don
> Pavel Stehule wrote:
>> 2009/2/17 Josh Berkus :
>>> All,
>>>
>>> I thought we'd agreed to compromise on having SE without row-level in
>>> 8.4,
>>> and working on SE with row-level in 8.5. Why are we revisiting this
>>> argument? 8.4 is *already* late; arguing further about the terms of SE
>>>
Pavel Stehule wrote:
2009/2/17 Josh Berkus :
All,
I thought we'd agreed to compromise on having SE without row-level in 8.4,
and working on SE with row-level in 8.5. Why are we revisiting this
argument? 8.4 is *already* late; arguing further about the terms of SE
simply risk us being forced t
2009/2/17 Josh Berkus :
> All,
>
> I thought we'd agreed to compromise on having SE without row-level in 8.4,
> and working on SE with row-level in 8.5. Why are we revisiting this
> argument? 8.4 is *already* late; arguing further about the terms of SE
> simply risk us being forced to reject it e
All,
I thought we'd agreed to compromise on having SE without row-level in
8.4, and working on SE with row-level in 8.5. Why are we revisiting
this argument? 8.4 is *already* late; arguing further about the terms
of SE simply risk us being forced to reject it entirely.
--Josh
--
Sent via
Jaime Casanova wrote:
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas wrote:
With reference to row-level security, most of the complaining about
this feature has been along the lines of "I don't like the idea that
rows get filtered from my result-set that I didn't ask to have
filtered".
yeah! b
Robert Haas wrote:
On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane wrote:
Robert Haas writes:
I'm a little bothered by this issue with respect to INSERT, UPDATE,
and DELETE, since it's possible that I have permission to see rows but
not updated them, and it would be a little weird if select and up
Robert Haas wrote:
I'm a little bothered by this issue with respect to INSERT, UPDATE,
and DELETE, since it's possible that I have permission to see rows but
not updated them, and it would be a little weird if select and update
with equivalent where clauses operated on different sets of records
(
Robert Haas wrote:
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane wrote:
I haven't seen anyone present a shred of evidence that this would be
the case in SE-PostgreSQL.
Sorry, but the burden of proof is in the other direction.
In any case, this was already discussed in detail in previous threads.
It is incorrect.
It seems to me you confound a covert channel and granularity in access
controls. The purpose of row-level security is to provide users more
flexibility in access controls, not related to covert channels.
No, I claim it's you that's confounding the data hiding scheme with
row-lev
Tom Lane wrote:
> Martijn van Oosterhout writes:
>> One thing I keep missing in this discussion: the term "row-level
>> security" in the above senstence in not the important part. Right now
>> you can revoke SELECT permission on a table with a foreign key and it
>> will still prevent UPDATEs and D
A couple of thoughts:
First off, I think the inclusion of row level security and an
unprecendented integration with OS level security are a stunning
example of what makes Open Source so much cooler than closed source
products. Great job! (and the speed of refactoring the patches was
pretty stunning
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas wrote:
>
> With reference to row-level security, most of the complaining about
> this feature has been along the lines of "I don't like the idea that
> rows get filtered from my result-set that I didn't ask to have
> filtered".
yeah! because was filte
On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm a little bothered by this issue with respect to INSERT, UPDATE,
>> and DELETE, since it's possible that I have permission to see rows but
>> not updated them, and it would be a little weird if select and update
>> with
Robert Haas writes:
> I'm a little bothered by this issue with respect to INSERT, UPDATE,
> and DELETE, since it's possible that I have permission to see rows but
> not updated them, and it would be a little weird if select and update
> with equivalent where clauses operated on different sets of r
On Mon, Feb 16, 2009 at 11:21 AM, Greg Stark wrote:
> On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas wrote:
>>
>> I'm not sure I understand what you mean by that. I expect that if I
>> deny a particular user access to SELECT from a particular table the
>> system will throw a permissions error if t
On 02/16/2009 04:23 PM, Kevin Grittner wrote:
Tom Lane wrote:
We have seen no evidence that anyone has a worked-out
set of design rules that make a SE-Postgres database secure against
these issues, so the whole thing is pie in the sky.
I've seen several mentions of the rule "Don't use a column
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas wrote:
>
> I'm not sure I understand what you mean by that. I expect that if I
> deny a particular user access to SELECT from a particular table the
> system will throw a permissions error if that user later enters
> "SELECT * FROM ". I don't expect t
On Mon, Feb 16, 2009 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> 2. Foreign-key constraints.
>> (A) If you have update or delete privileges on a table that is
>> referenced by foreign keys, you might be able to infer the existence
>> of a hidden, referring row because your update or del
Robert Haas writes:
> 2. Foreign-key constraints.
> (A) If you have update or delete privileges on a table that is
> referenced by foreign keys, you might be able to infer the existence
> of a hidden, referring row because your update or delete fails.
Also the other direction (insert or update on
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane wrote:
>> I haven't seen anyone present a shred of evidence that this would be
>> the case in SE-PostgreSQL.
>
> Sorry, but the burden of proof is in the other direction.
>
> In any case, this was already discussed in detail in previous threads.
> It's po
"Kevin Grittner" writes:
> Tom Lane wrote:
>> We have seen no evidence that anyone has a worked-out
>> set of design rules that make a SE-Postgres database secure against
>> these issues, so the whole thing is pie in the sky.
> I've seen several mentions of the rule "Don't use a column contain
>>> Tom Lane wrote:
> We have seen no evidence that anyone has a worked-out
> set of design rules that make a SE-Postgres database secure against
> these issues, so the whole thing is pie in the sky.
I've seen several mentions of the rule "Don't use a column containing
data you want to secure a
Robert Haas writes:
> ... so the question is not "Are there covert channels?" but "Are the
> covert channels sufficiently large so as to render the system not
> useful in the real world?".
Fair enough.
> I haven't seen anyone present a shred of evidence that this would be
> the case in SE-Postgr
>>> Andres Freund wrote:
> I guess he is talking about 2009PA23 being a foreign key - about
> which you could get information via the aforementioned covert
channels,
> even if you cannot read that row.
Exactly. Sorry I didn't make that more clear.
-Kevin
--
Sent via pgsql-hackers mai
On Mon, Feb 16, 2009 at 9:53 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Gregory Stark wrote:
>>> And it doesn't accomplish anything since the covert
>>> channels it attempts to address are still open.
>
>> Hyperbole. We're not very likely to go the SE-* route, but I can say
>> that we've
>>> Tom Lane wrote:
> "Kevin Grittner" writes:
>> Gregory Stark wrote:
>>> And it doesn't accomplish anything since the covert
>>> channels it attempts to address are still open.
>
>> Hyperbole. We're not very likely to go the SE-* route, but I can
say
>> that we've got some of the issues i
Hi,
On 02/16/2009 03:53 PM, Tom Lane wrote:
Hyperbole. We're not very likely to go the SE-* route, but I can say
that we've got some of the issues it addresses, and it is a very
different thing for someone to know, for example, that there is a
paternity case 2009PA23 in a county, and for th
>> Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
>> eliminate information leaks via such kind of covert channels, so they
>> don't violate any specifications of them. Thus, it is not a problem.
>
> If that's true then I don't see why we would try to automatically hide reco
Martijn van Oosterhout writes:
> One thing I keep missing in this discussion: the term "row-level
> security" in the above senstence in not the important part. Right now
> you can revoke SELECT permission on a table with a foreign key and it
> will still prevent UPDATEs and DELETEs of the primary
"Kevin Grittner" writes:
> Gregory Stark wrote:
>> And it doesn't accomplish anything since the covert
>> channels it attempts to address are still open.
> Hyperbole. We're not very likely to go the SE-* route, but I can say
> that we've got some of the issues it addresses, and it is a very
>
On Mon, Feb 16, 2009 at 12:08 PM, KaiGai Kohei wrote:
This is the same "covert channel", so why is it a problem for
SE-Postgres and not for normal Postgres?
>>>
>>> Please note that I don't consider it is a problem, even if SE-PostgreSQL.
>>>
>>> Both of SE-PostgreSQL and vanilla Postgre
On Mon, Feb 16, 2009 at 10:54:32AM +, Gregory Stark wrote:
> > Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
> > eliminate information leaks via such kind of covert channels, so they
> > don't violate any specifications of them. Thus, it is not a problem.
>
> If that'
>>> Gregory Stark wrote:
>And it doesn't accomplish anything since the covert
>channels it attempts to address are still open.
Hyperbole. We're not very likely to go the SE-* route, but I can say
that we've got some of the issues it addresses, and it is a very
different thing for someo
This is the same "covert channel", so why is it a problem for
SE-Postgres and not for normal Postgres?
Please note that I don't consider it is a problem, even if SE-PostgreSQL.
Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
eliminate information leaks via such kind of co
KaiGai Kohei writes:
> Martijn van Oosterhout wrote:
>> On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
>>> 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-lev
Martijn van Oosterhout wrote:
> On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
>> 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
On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
> 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
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 othe
> 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
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 ot
[..]
>> 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 applicati
BogDan Vatra wrote:
I've tested you patch in windows and in linux and it just work, it's a
killer feature. I have to tank you and all who worked on this.
On windows I have one little problem, mingw does not have "strtok_r"
function and I have to add it myself (see attached file).
Indeed, I coul
Hi,
[...]
>
> In my understanding, the row-level ACLs feature (plus a bit enhancement)
can
> help your requirements. I developed it with SE-PostgreSQL in parallel,
but also postponed to v8.5 series.
> It enables to assign database ACLs on individual tuples, and filter out
violated tupled from the r
BogDan, Thanks for your interesting.
At first, I would like to confirm whether you know the row-level security
feature is postponed to v8.5, or not. Thus, the latest patch set (toward
v8.4 development cycle) does not contain the row-level one.
Please note that the following my comments assume the
45 matches
Mail list logo
