Andrew, Marc,
> FWIW, I sup****t and think im****tant the row- and column- level access
> controls this seems to be proposing, at least in principle. Whether
> that's a sup****t 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 sup****t that trade-off).
Well, there are two different goals we can satisfy. One is to help
sup****t 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@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
