Alvaro Herrera wrote: > Gregory Stark escribió: >> Heikki Linnakangas <heikki.linnakan...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
