> Yeah, that's what I keep hearing that the spooks think they want. > I can't imagine how it would play nice with SQL-standard integrity > constraints. Data that apparently violates a foreign-key constraint, > for example, would give someone a pretty good clue that there's > something there he's not being allowed to see.
Right, so you don't let that happen. If you're giving Mr. X access to the "cities" table, and decide to restrict him only to cities in Europe, then if you give him access to the "informants" table, you'll probably restrict that to only informants located in cities that are in Europe, so, no problem. It's easy to come up with cases where there is a problem but just because there can be problems doesn't mean the technology isn't basically useful. I don't think there's much point in second-guessing the NSA: they are smart and have thought about this more than we have. But I do think it's worthwhile to ask whether it makes sense to introduce a bunch of features that are only usable to people running SELinux. Column-level permissions are the best example of this: it's very easy to imagine people wanting that feature, but NOT being willing to run SELinux to get it. It's more arguable whether data hiding falls into the same category or not, because if you're doing data hiding then arguably you're a security nut and more likely to be running (or willing to run) SELinux. Against that, my boss made me do data hiding but we have no interest in SELinux, so that's one data point the other way, though not one I'd take all that seriously. So far there has been no detailed discussion of any of the new security features that are in this patch (column-level security, row-level security, large object security, etc). For each of those features, we need to answer the following questions: 1. Do we want this feature as a part of PostgreSQL at all? 2. If #1 is yes, do we eventually want to expose this feature via a SQL interface, or some other interface substantially unlike SE-PostgreSQL? 3. If #2 is yes, will accepting this patch get us closer to that goal or further away from it? I suspect that for most of the features the answer for #1 will be yes, but the other two questions need some more careful examination. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
