(2010/01/14 15:04), Greg Smith wrote:
KaiGai Kohei wrote:
(2010/01/14 4:54), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lanet...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Some of ALTER TABLE operations take multiple permission checks, not only
ownership of the relation to be altered.
Yes, exactly my point. Those places typically just presume that the
owner check has already been done.
For example, ALTER TABLE with
On Thu, Jan 14, 2010 at 1:04 AM, Greg Smith g...@2ndquadrant.com wrote:
But the preference of the last CF is to not apply any patch which doesn't
have a very clear justification to be committed. Given that whether this
patch is applied or not to 8.5 really doesn't make any functional
(2010/01/14 23:29), Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Some of ALTER TABLE operations take multiple permission checks, not only
ownership of the relation to be altered.
Yes, exactly my point. Those places typically just presume that the
owner check has
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian br...@momjian.us wrote:
I agree. Why are arbitrary restrictions being placed on code
improvements? If code has no purpose, why not remove it, or at least
mark it as NOT_USED.
So, where do we go from
Robert Haas robertmh...@gmail.com wrote:
So, where do we go from here? Any other opinions?
It seems that we often have people cleaning up redundant or
unreachable code to improve code clarity. I'm not in a position
right now to confirm that this code is redundant, but if that has
been
On Wed, Jan 13, 2010 at 1:15 PM, Robert Haas robertmh...@gmail.com wrote:
So, where do we go from here? Any other opinions?
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we know exactly what the
plan is?
The chances of getting concensus on an
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 11, 2010 at 8:27 PM, Bruce Momjian br...@momjian.us wrote:
I agree. Why are arbitrary restrictions being placed on code
improvements? If code has no purpose, why not
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine with it,
but that's not clear either. The argument for
On Wed, Jan 13, 2010 at 12:54, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a little worried by Stephen's plan, mainly because I'm concerned
that it would lead to ALTER TABLE taking exclusive lock on a table long
before it gets around to checking permissions. Still, that's just
extending a window
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker bada...@gmail.com wrote:
Im of the opinion if we are going to be meddling with the permission
checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like most solutions would put us back to exactly what
* Alex Hunsaker (bada...@gmail.com) wrote:
On Wed, Jan 13, 2010 at 12:54, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a little worried by Stephen's plan, mainly because I'm concerned
that it would lead to ALTER TABLE taking exclusive lock on a table long
before it gets around to checking
* Alex Hunsaker (bada...@gmail.com) wrote:
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker bada...@gmail.com wrote:
Im of the opinion if we are going to be meddling with the permission
checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like
Alex Hunsaker bada...@gmail.com writes:
Im of the opinion if we are going to be meddling with the permission
checks in this area one of the goals should be close or at least
tighten up that window. So you cant lock a table you dont have
permission to (either via LOCK or ALTER TABLE).
(2010/01/14 4:54), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lanet...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine with it,
but that's
(2010/01/14 4:27), Stephen Frost wrote:
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we know exactly what the
plan is?
KaiGai Kohei wrote:
(2010/01/14 4:54), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Jan 13, 2010 at 1:34 PM, Tom Lanet...@sss.pgh.pa.us wrote:
If I thought this patch represented incremental movement in the
direction of a better security-check factorization, I'd be fine
Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan for how to organize all of our permissions checks
ought to keep us
(2010/01/12 10:27), Bruce Momjian wrote:
Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:54 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan for how to organize all of our
On Sun, Dec 20, 2009 at 10:53 PM, I wrote:
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly
Robert Haas robertmh...@gmail.com writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan for how to organize all of our permissions checks
ought to keep us from removing this one on the grounds of redundancy.
We have to attack this problem in small
On Sun, Jan 10, 2010 at 4:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I have looked this over a little bit and I guess I don't see why the
lack of a grand plan for how to organize all of our permissions checks
ought to keep us from removing this one on
2009/12/22 KaiGai Kohei kai...@ak.jp.nec.com:
(2009/12/21 12:53), Robert Haas wrote:
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
KaiGai Koheikai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch,
(2009/12/21 12:53), Robert Haas wrote:
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
KaiGai Koheikai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The patch was not attached...
This patch either does too much, or not enough.
I would either leave the Assert() in-place as a double-check (I presume
that's why it was there in the first place, and if that Assert() fails
then our assumption
(2009/12/18 6:38), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The patch was not attached...
This patch either does too much, or not enough.
I would either leave the Assert() in-place as a double-check (I presume
that's why it was there in the first place,
KaiGai Kohei kai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of plan about
where they ought to go. There are two principal entry
On Thu, Dec 17, 2009 at 7:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we're going to start moving these checks around we need a very
well-defined notion of where permissions checks should be made, so that
everyone knows what to expect. I have not seen any plan for that.
Removing one check at
* Tom Lane (t...@sss.pgh.pa.us) wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of plan about
where they
* Robert Haas (robertmh...@gmail.com) wrote:
Disentangling that seems like a job and a half.
Indeed it will be, but I think it would be a good thing to actually have
a defined point at which permissions checking is to be done. Trying to
read the code and figure out what permissions you need to
On Thu, Dec 17, 2009 at 10:14 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Disentangling that seems like a job and a half.
Indeed it will be, but I think it would be a good thing to actually have
a defined point at which permissions checking is to
(2009/12/18 9:19), Tom Lane wrote:
KaiGai Koheikai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of plan about
where they ought to
It is a cleanup patch apart from SELinux and security framework.
Now, EnableDisableRule() checks ownership of the relation which
owns the rewrite rule to be enabled/disabled.
But it has the following call path, and this check is already done
in the ATPrepCmd().
ATExecCmd()
-
The patch was not attached...
(2009/12/16 15:15), KaiGai Kohei wrote:
It is a cleanup patch apart from SELinux and security framework.
Now, EnableDisableRule() checks ownership of the relation which
owns the rewrite rule to be enabled/disabled.
But it has the following call path, and this
37 matches
Mail list logo
