Re: [0/4] Proposal of SE-PostgreSQL patches

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