In a digest for Tue, 2008-05-06 at 22:57 -0300, Tom Lane wrote: ...[discussion of SE-PostgreSQL patch deleted]... > (And of course the next question after that is why we should want to > depend on SELinux at all, rather than implementing row filtering > in the framework of SQL permissions...)
I would love to see something like this to replace Veil which I develop and support. What sort of row filtering did you have in mind? As a database application developer I have found being able to define access controls in terms of data relationships to be tremendously useful and I would love to see something like this built into postgres. As far as I have been able to understand SE-PostgreSQL, it is aimed at a very security-conscious, and expert, customer base but it cannot offer the sort of relationally-defined security access that Veil is intended for (I'd be happy to be wrong about this). On the other hand Veil is not going to be able to provide the degree of certainty (provability?) of SE-PostgreSQL. As an example of relationally-defined security, suppose I want only the members of a project team to be able to see project information: In the veil demo application ( http://veil.projects.postgresql.org/curdocs/demo-model.html ) we can assign a developer to a project by inserting into the assignments table a record for that developer, the given project and a specific role. Once assigned, the developer can see project_details for that project that previously were unavailable. If row filtering is to be implemented directly within Postgres, I would like this sort of capability to be considered. For the record, Veil was written to provide similar functionality to Oracle's Virtual Private Databases. __ Marc
signature.asc
Description: This is a digitally signed message part