Re: Privileges and inheritance

> 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