Re: security label support, part.2

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > No..  and I'm not sure we ever would.  What we *have* done is removed
> > all permissions checking on child tables when a parent is being
> > queried..
>
> Yeah. I'm not totally sure that is sensible for a MAC environment.
> Heck, it's arguably incorrect (though perhaps quite convenient) in a
> DAC environment. Anyway, I wonder if it would be sensible to try to
> adjust the structure of the DAC permissions checks so enhanced
> security providers can make their own decision about how to handle
> this case.

To be honest, I don't really like the way this is done at all. I'd
rather have it such that if and when a table is made a child of another
table, it should inherit the permissions of the parent and be kept that
way, or it should be completely independent (which is the situation we
used to have), or, last resort, we should complain when they don't
match.

Or we could just not error when we hit a child table that the caller
doesn't have access to (but also not return the records). The problem
is that we've got different users that want to use inheiritance for very
different purposes and we havn't got a way to address all of them. I do
worry that we're going to regret making the change to not check
permissions on child tables, but at the same time, any query which would
have been impacted by that would have failed, so that really begs the
question of "do people really use/want different permissions on child
tables than the parent?". I tend to think 'no', and would rather force
them and keep them the same, but maybe that's just me..

Thanks,

Stephen