Peter Eisentraut writes:
> If I'm seeing this right, it's literally a one-line fix.
At least a two-line fix, please: that needs a comment. But yeah,
I think that's basically all that would have to change.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
On Sat, 2009-10-03 at 09:45 +0300, I wrote:
> So let's get rid of that. Selecting (or in general, operating) on a
> table with children only checks the privileges on that table, not the
> children.
If I'm seeing this right, it's literally a one-line fix. Patch attached
with documentation and te
Tom Lane wrote:
> KaiGai Kohei writes:
>> Was it uncertain what I wanted to say for the proposition?
>
> No: it's that nobody sees any particular value in making a fundamental
> restructuring of the permissions system like that. What you propose
> would be far harder/more complicated to implemen
KaiGai Kohei writes:
> Was it uncertain what I wanted to say for the proposition?
No: it's that nobody sees any particular value in making a fundamental
restructuring of the permissions system like that. What you propose
would be far harder/more complicated to implement, to understand,
or to use
Was it uncertain what I wanted to say for the proposition?
In my understanding, here are two different perspectives to handle
table inheritances.
The one handles the inherited definitions of child tables as a part
of the child table. The current implementation uses this perspective.
Thus, it chec
On Mon, 2009-10-05 at 11:58 -0700, Josh Berkus wrote:
> Simon,
>
> > A small addition though, please. This functionality has been available
> > since 8.1 and changing things could cause existing people's scripts to
> > fail when they upgrade. If we make this change then we should make sure
> > th
Simon,
> A small addition though, please. This functionality has been available
> since 8.1 and changing things could cause existing people's scripts to
> fail when they upgrade. If we make this change then we should make sure
> that explicitly GRANTing a permission on the child tables does not fa
On Mon, 2009-10-05 at 10:27 -0700, Josh Berkus wrote:
> Simon,
>
> >> We could use a GUC variable to ease the transition, perhaps like
> >> sql_inheritance = no | yes_without_privileges | yes
> >
> > The original way of doing things was quite useful if you wanted some
> > people to be able to se
On Mon, 2009-10-05 at 11:45 +0100, Simon Riggs wrote:
> On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
> > On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
> > > top level: data-template
> > > main tables: data, data-recent both inherit from data-template
> > > all partitions inher
Simon,
>> We could use a GUC variable to ease the transition, perhaps like
>> sql_inheritance = no | yes_without_privileges | yes
>
> The original way of doing things was quite useful if you wanted some
> people to be able to see history and others just see recent data. I
> don't think many peopl
On Mon, 2009-10-05 at 10:14 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
> >> I don't see where the problem is here.
>
> > In your last post you said it was necessary to use ONLY to address the
> > required partitions and so setup wo
Simon Riggs writes:
> On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
>> I don't see where the problem is here.
> In your last post you said it was necessary to use ONLY to address the
> required partitions and so setup would be weird. I am showing that this
> is not required and the s
On Mon, 2009-10-05 at 13:06 +0300, Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
> > top level: data-template
> > main tables: data, data-recent both inherit from data-template
> > all partitions inherit from data
> > only recent partitions inherit from data-recen
On Mon, 2009-10-05 at 10:47 +0100, Simon Riggs wrote:
> top level: data-template
> main tables: data, data-recent both inherit from data-template
> all partitions inherit from data
> only recent partitions inherit from data-recent
> grants are issued on data and data-recent
I don't see where the p
On Mon, 2009-10-05 at 12:30 +0300, Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 09:22 +0100, Simon Riggs wrote:
> > On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
> >
> > > We could use a GUC variable to ease the transition, perhaps like
> > > sql_inheritance = no | yes_without_pri
On Mon, 2009-10-05 at 09:22 +0100, Simon Riggs wrote:
> On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
>
> > We could use a GUC variable to ease the transition, perhaps like
> > sql_inheritance = no | yes_without_privileges | yes
>
> The original way of doing things was quite useful i
Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
>> CREATE TABLE tbl_p (int a, int b);
>> CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
>>
>> SELECT a,b FROM tbl_p; --> It selects data from only tbl_p.
>> It is reasonable to bypass checks o
On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
> CREATE TABLE tbl_p (int a, int b);
> CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
>
> SELECT a,b FROM tbl_p; --> It selects data from only tbl_p.
> It is reasonable to bypass checks on tbl_c.
> SELECT b,x FROM tbl
On Sat, 2009-10-03 at 09:45 +0300, Peter Eisentraut wrote:
> We could use a GUC variable to ease the transition, perhaps like
> sql_inheritance = no | yes_without_privileges | yes
The original way of doing things was quite useful if you wanted some
people to be able to see history and others jus
Peter Eisentraut wrote:
> On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
>> On the other hand, it also needs to check permission both of child
>> table and its parents when we select data from a table with its
>> parents,
>
> You can't do that anyway.
Sorry, I'm not clear why it is imposs
On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
> On the other hand, it also needs to check permission both of child
> table and its parents when we select data from a table with its
> parents,
You can't do that anyway.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Peter Eisentraut wrote:
> I would like to propose a change in the way privilege checking is done
> with inheritance hierarchies. Currently, selecting from a table that
> has children requires explicit privileges on all the children. This is
> inconsistent with all other commands, which treat chil
Peter Eisentraut writes:
> On Sun, 2009-10-04 at 11:56 -0700, Josh Berkus wrote:
>> And we'd want to hammer this to death looking for ways it can be a
>> security exploit. Like, could you make a table into the parent of an
>> existing table you didn't have permissions on?
> I don't think so, but
On Sun, 2009-10-04 at 11:56 -0700, Josh Berkus wrote:
> Except ... I can imagine a multi-tenant setup where certain ROLEs only
> have permissions on some child relations, but not others. So we'd want
> to still enable a permissions check on a child when the child is called
> directly rather than t
> So let's get rid of that. Selecting (or in general, operating) on a
> table with children only checks the privileges on that table, not the
> children. Is there any use case where the current behavior is useful at
> all?
In theory, someone out there may be using privs to restrict access to
c
Peter Eisentraut writes:
> So let's get rid of that. Selecting (or in general, operating) on a
> table with children only checks the privileges on that table, not the
> children.
+1
> We could use a GUC variable to ease the transition, perhaps like
> sql_inheritance = no | yes_without_privilege
I would like to propose a change in the way privilege checking is done
with inheritance hierarchies. Currently, selecting from a table that
has children requires explicit privileges on all the children. This is
inconsistent with all other commands, which treat children as implicitly
part of the p
27 matches
Mail list logo
