From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Privileges and inheritance |
Date: | 2009-10-04 18:56:01 |
Message-ID: | 4AC8EFC1.1050209@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
child tables. In practice, this would be unmanageable enough that I
doubt anyone is doing it intentionally.
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 through the parent.
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?
> We could use a GUC variable to ease the transition, perhaps like
> sql_inheritance = no | yes_without_privileges | yes
no | without_privileges | yes
Mind you, this is a boolean now, isn't it?
--Josh Berkus
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Colish | 2009-10-04 19:07:53 | Re: Rules: A Modest Proposal |
Previous Message | Pavel Stehule | 2009-10-04 18:48:15 | Re: Rules: A Modest Proposal |