Pavel Stehule wrote:
2009/2/17 Josh Berkus j...@agliodbs.com:
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
Greg Stark wrote:
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas robertmh...@gmail.com 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
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
2009/2/17 Josh Berkus j...@agliodbs.com:
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
Pavel Stehule wrote:
2009/2/17 Josh Berkus j...@agliodbs.com:
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
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 or
KaiGai Kohei kai...@ak.jp.nec.com 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,
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
Gregory Stark st...@enterprisedb.com 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 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's true
On Mon, Feb 16, 2009 at 12:08 PM, KaiGai Kohei kai...@kaigai.gr.jp 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Gregory Stark st...@enterprisedb.com 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
Martijn van Oosterhout klep...@svana.org 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
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 records
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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Gregory Stark st...@enterprisedb.com 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,
On Mon, Feb 16, 2009 at 9:53 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Gregory Stark st...@enterprisedb.com wrote:
And it doesn't accomplish anything since the covert
channels it attempts to address are still open.
Hyperbole. We're not very
Andres Freund and...@anarazel.de 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
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Mon, Feb 16, 2009 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas robertmh...@gmail.com 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
On 02/16/2009 04:23 PM, Kevin Grittner wrote:
Tom Lanet...@sss.pgh.pa.us 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
On Mon, Feb 16, 2009 at 11:21 AM, Greg Stark st...@enterprisedb.com wrote:
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas robertmh...@gmail.com 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!
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
Tom Lane wrote:
Martijn van Oosterhout klep...@svana.org 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
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
Robert Haas wrote:
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us 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
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 11:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Jaime Casanova wrote:
On Mon, Feb 16, 2009 at 12:18 PM, Robert Haas robertmh...@gmail.com 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
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
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
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 is
[..]
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
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
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 could
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
Hi,
I need SE-PostgreSQL *ONLY* for row level security, but AFAIK
SE-PostgreSQL
works only on SELinux. This, for me, is unacceptable, because I want to use
row level security on windows too. I don't need all that fancy security
stuffs.
I want to share with you my security experience,
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
46 matches
Mail list logo
