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
On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote:
Will a program built with ecpg 8.4 run against a 7.4 server work the
same as the same program built with ecpg 7.4 run against a 7.4 server?
(This implies that the program uses only features present in 7.4.)
No, if the
On Monday 16 February 2009 12:06:55 Michael Meskes wrote:
On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote:
Will a program built with ecpg 8.4 run against a 7.4 server work the
same as the same program built with ecpg 7.4 run against a 7.4 server?
(This implies that the
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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cédric Villemain a écrit :
Joshua D. Drake a écrit :
On Thu, 2009-02-12 at 11:47 -0500, Andrew Dunstan wrote:
Joshua D. Drake wrote:
On Thu, 2009-02-12 at 11:32 -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The
On Mon, Feb 16, 2009 at 12:39:32PM +0200, Peter Eisentraut wrote:
On Monday 16 February 2009 12:06:55 Michael Meskes wrote:
On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote:
Will a program built with ecpg 8.4 run against a 7.4 server work the
same as the same program built
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
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle, but
for first iteration it is good.
postgres=# select length('') is null;
?column?
--
t
(1 row)
I thing, so this
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 02:35:54PM +0100, Pavel Stehule wrote:
attachment contains module that transform every empty string to null.
Why would anyone ever want to do this? This would appear to break all
sorts of things in very non-obvious ways:
SELECT CASE s WHEN '' THEN 'empty string' ELSE
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
attachment contains module that transform every empty string to null.
Why would anyone ever want to do this? This would appear to break all
sorts of things in very non-obvious ways:
I
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
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
attachment contains module that transform every empty string to null.
Why would anyone ever want to do this? This would
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
Pavel Stehule pavel.steh...@gmail.com writes:
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle,
Surely a parser hook like this would have nothing whatsoever to do
with
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
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 02:35:54PM +0100, Pavel Stehule wrote:
attachment contains module that transform every empty string to null.
Why would
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
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
- Are there any limitations in casting to anyelement?
It's a no-op ... probably we shouldn't even let you do it, if the
lack of an error leaves room for such misinterpretation as this.
anyelement and friends are placeholders for use in
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 12:10 PM, Cédric Villemain
cedric.villem...@dalibo.com wrote:
is -j already affected ?
else (like make):
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run simultaneously. If the -j
option is given without an argument, pg_restore will not
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
Joshua D. Drake wrote:
Thanks for the work around, but that is ridiculous. I still say this is
a bug.
Yes, which is why we fixed it on 8.4 by dropping pg_autovacuum. (As
Jaime and Tom say, it's actually pilot error, but the UI is crap so we
fixed it.)
--
Alvaro Herrera
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!
On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
so these modules (decode, oraemptystr) decrease differences between
PostgreSQL and Oracle.
wouldn't it be better/easier
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
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 04:40:23PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 03:21:12PM +0100, Pavel Stehule wrote:
so these modules (decode, oraemptystr) decrease differences between
PostgreSQL and
On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
But to do it properly inside PG would be difficult; how would your hooks
know to transform:
SELECT s FROM foo WHERE s IS NULL;
into:
SELECT s FROM foo WHERE (s = '' OR s IS
2009/2/16 Sam Mason s...@samason.me.uk:
On Mon, Feb 16, 2009 at 08:03:42PM +0100, Pavel Stehule wrote:
2009/2/16 Sam Mason s...@samason.me.uk:
But to do it properly inside PG would be difficult; how would your hooks
know to transform:
SELECT s FROM foo WHERE s IS NULL;
into:
2009/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle,
Surely a parser hook like this would
Hello
I found BNF for SQL 2003 and I found there some small difference.
Standard use keyword ESCAPE, but PostgreSQL use keybord UESCAPE.
Anybody knows reason?
Unicode character string literal::=
[ introducer character set specification ]
U ampersand quote [ Unicode
Cédric Villemain wrote:
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (pg_restore) to run simultaneously. If the -j
option is given without an argument, pg_restore will not limit the number of
jobs that can run simultaneously.
Quite apart from anything else, this
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
The attached is a patch to change 3 things:
- Reject toast.fillfactor.
- Modify relopt_kind to bit flags.
- Report relation type on unrecognized parameter errors.
I registered the patch as an open item:
Tom Lane t...@sss.pgh.pa.us wrote:
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
- Are there any limitations in casting to anyelement?
It's a no-op ... probably we shouldn't even let you do it, if the
lack of an error leaves room for such misinterpretation as this.
anyelement
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Tom Lane t...@sss.pgh.pa.us wrote:
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
- Are there any limitations in casting to anyelement?
It's a no-op ... probably we shouldn't even let you do it, if the
lack of an error leaves
I reported the following bug to -bugs, and I'd like to discuss
whether we need to fix the issue or how to fix it.
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
Bug reference: 4660
PostgreSQL version: 8.3.3
Operating system: Fedora 8
Description:float functions return
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
Peter Eisentraut wrote:
Tom Lane wrote:
Is this acceptable to everyone? We could name the option
-u/--upgrade-compatible.
If the switch is specifically for pg_upgrade support (enabling this as
well as any other hacks we find necessary), which seems like a good
idea, then don't chew
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
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
We already have some codes to avoid -0 float8um (unary minus),
but there are no protection in trunc(), ceil() and round() at least.
I looked into the CVS history to find out when the anti-minus-zero code
got put into float8um. It seems to
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
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
- Postgres interprets 'on' as true and 'off' as false in configuration
parameters, but they are not accepted in sql-boolean.
Is it a design? or should we add a parser for 'on' and 'off' ?
I'd like to allow 'on' and 'off' in
59 matches
Mail list logo
