On Thu, Sep 25, 2008 at 08:57:46PM -0400, Tom Lane wrote: > Another point is that the proposed behavior leaks quite a lot of > information, since it will fail operations on the basis of tuples that > supposedly aren't visible to the invoking user. While I admit that it's > hard to see an alternative if we're to preserve FK integrity, I have to > worry that this definition isn't going to satisfy the tin-foil-hat > brigade that are supposed to be the main users of SEPostgres. If the > goal is "you don't know the row is there", this doesn't seem to meet it.
The above point, and other similar ones in every discussion of the proposed functionality, makes me think once again either that the requirements for this feature aren't understood by everyone, or else that they're not actually explicit enough. I have a feeling it's the latter. Certainly, I've not yet read a complete security analysis of a data system security plan that outlines why the proposed model is correct. What I think is really happening with this development is that the SE-Linux understanding of "security enhancement" has been taken as the correct analysis for how one secures an information system. That deep assumption appears to me to be informing much of the development of SE-PostgreSQL. In particular, that deep assumption includes an assumption that consistency of access control trumps all. The Postgres developers who are questioning the SE approach are (I think) coming at this from the point of view of data systems developers, where consistency of the data set trumps all. I suspect that the tension between these approaches will not be reconciled without a fairly complete outline of possible security models for data systems, their relationship to what the OS security people have decided is the right thing to do, and the trade-offs necessary to make different priorities work. Some of the trade offs may include things like "violate traditional understanding of data set consistency" and "possible disclosure of existence of datum". I think this will be a lot of work, and I'm not volunteering to do it. I nevertheless think that without it, the SE-PostgreSQL features will continue to be a very awkward fit. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers