Re: security label support, part.2

(2010/08/18 9:04), Stephen Frost wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>> 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.
>>
>> IIRC, the reason we did it was that we decided the SQL spec requires it.
>> So there's not a lot of point in debating the issue, unless you can
>> convince us we misread the spec.
>
> I've not gone through the spec with regard to this (yet..), but I think
> we need to consider the whole 'principle of least surprise' here,
> regardless of what the spec says. For one thing, this isn't how older
> versions of PG behaved and while I doubt anyone intended to rely on that
> behavior, it makes me nervous that someone, somewhere, unintentionally
> relies on it.
>
I believed that table inheritance is a unique feature in PostgreSQL.
Does the SQL spec really mention about whether a child table is an
independent table object, or not?
Or, are you talking about the behavior that parent's permission also
controls accesses on child tables? If so, all of us already agreed.

> What I'm thinking of is something like a warning if the permissions on
> the child don't match those of the parent when the relationship is
> created, or maybe forcibly setting the permissions on the child (with a
> NOTICE), so it's at least clear what is going on. Or perhaps, set the
> permissions on the child only if it doesn't have permissions (with the
> NOTICE), and issue a WARNING if the child already has permissions set.
> Perhaps also a WARNING if someone changes the permissions on a child
> after the relationship has been created too, but let it happen in case
> someone really wants it..
>
> I dunno. None of the above makes me feel very comfortable from a
> security perspective because I'm concerned any of the above could too
> easily be overlooked by someone upgrading. It also doesn't really
> address the concern that, at some point, a child table could have
> different permissions than a parent table. If we forcibly set the
> permissions on the child, or ERROR'd if the permissions weren't either
> the same or empty on the child, and then ERROR'd if someone tried to
> change the child's permissions later, I'd be happier.
>
I also think ERROR should be raised when user tries to assign different
security properties on child tables from its parent. At least, I think
it should be configurable using a guc variable.
If WARNING/NOTICE, we can easily break consistency of the permissions...

> I don't really want to force people doing routine partition additions
> to have to set the permissions on the child before adding it, but I
> also don't want to have to figure out "are these two sets of permissions
> identical", since that's not really trivial to determine. We do have
> default permissions now though, so maybe requiring the permissions be
> the same from the get-go is the right idea. Of course, if we change the
> permissions on the child when the inheiritance relationship is created,
> we'll need to update those perms every time the parents perms are
> changed.
>
I also think it is a good idea to copy permissions from the parent when
we try to define an inheritance relationship. It obviously reduces user's
routine task on defining many of child tables. It seems to me a case when
we provide a NOTICE to users, if permissions of child table is overwritten.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>