Re: 8.4 release planning
Joshua Brindle <method@manicmethod.com>
From: Joshua Brindle <method@manicmethod.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>, Gregory Stark <stark@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndQuadrant.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, "Joshua D. Drake" <jd@commandprompt.com>, Merlin Moncure <mmoncure@gmail.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, Bruce Momjian <bruce@momjian.us>, Bernd Helmle <mailings@oopsware.de>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2009-01-27T19:39:23Z
Lists: pgsql-hackers
Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> This seems to me to be exactly parallel to deciding that SELinux should >> control only table/column permissions within SQL; an approach that would >> be enormously less controversial, less expensive, and more reliable than >> what SEPostgres tries to do. > > While also ignoring a feature that is available, and used by these same > security communities, in other enterprise RDBMSs... > > http://www.securityfocus.com/infocus/1743 > > http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx > > It's not codified in the SQL spec (yet..) that I saw, and maybe we could > seperate out the SE bits from the row-level bits, but I'm really not > sure I see the value in doing that.. They are separate. If you look at the patches you'll see a pgace part, this is where the core interfaces to the security backends, and you'll see a rowacl backend and an sepgsql backend. Personally I'd like to see all of the access control moved out to use pgace, including the standard DAC permissions but I doubt that would never happen.