Andrew, Marc,
FWIW, I support and think important the row- and column- level access controls this seems to be proposing, at least in principle. Whether that's a support that will extend to 2x overhead on everything is rather a different matter. Also, I am more than prepared to trade away some cases in order to get a broadly useful functionality (so if you can't hide the existence of a table, but all efforts to learn its contents don't work, I might be willing to support that trade-off).
Well, there are two different goals we can satisfy. One is to help support the kind of VPS functionality that Veil is designed for, and the majority of users want. The second goal is upholding the kind of security systems demanded by highly secure environments which have statutory requirements about how security should work.
That is, while Veil-like funcitonality is what most developers want, it's not what NSA/Banks/military want, who have their own ideas about security. I think we can conceivably capture both.
I do think that SE functionality which goes beyond reasonable SQL requirements should be a build-time options because I don't feasably see ways to implement them that won't cause a big performance hit.
Also, I think you should be aware that for serious multilevel security hackers (one of whom will be working on Postgres soon) SEPostgres is the beginning and not the end. One of the requirements of many militaries, for example, is not merely data hiding by data substitution, where the row contents you see depend on your security clearance.
Also, re: pg_dump: it's actually a desired feature that, for example, some users only be able to dump a subset of the database. Including some DBAs. One of the issues which SE/Mulitlevel tries to address is "what happens if you don't trust your DBA 100%?" So if we can retain that, it's actually a feature and not a bug.
--Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
