Re: security label support, part.2

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.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.

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 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.

Just my 2c.
Thanks,
    Stephen