Alvaro Herrera wrote:
> Gregory Stark escribió:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>
>>> KaiGai Kohei wrote:
>>>> * [..feature description..]
>>> This again falls into the category of trying to have more fine-grained
>>> permissions than vanilla PostgreSQL has....
>> Would it make sense to instead of removing and deferring pieces bit by bit to
>> instead work the other way around? Extract just the part of the patch that
>> maps SELinux capabilities to Postgres privileges as a first patch? Then
>> discuss any other parts individually at a later date?
>
> I think that makes sense. Implement just a very basic core in a first
> patch, and start adding checks slowly, one patch each. We have talked
> about "incremental patches" in the past.
+1 from an end-user's point of view too.
I'm quite aware of the postgres privileges, and if there were a MAC
system of enforcing those I'd be reasonably likely to enable them
right away.
On the other hand, if SEPostgres initially comes with a different set
of privileges that don't map to what I'm already using, I'm much less
likely to spend the time to figure out the two different systems.
And I do see row-level restrictions (and the other access restrictions
mentioned in this thread) as quite orthogonal to MAC vs DAC. Would it
be cool to have row-level permissions in postgres? Sure, as an abstract
concept. Do I have any use for them? Seeing that I'm getting by
without them, the answer must be "not now".
> We wouldn't get "unbreakable PostgreSQL" in a single commit, but we
> would at least start moving.
>
> The good thing about having started in the opposite direction is that by
> now we know that the foundation APIs are good enough to build the
> complete feature.