* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 17, 2010 at 1:50 PM, Stephen Frost <sfr...@snowman.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
signature.asc
Description: Digital signature