> It may be the case that clean row and column filtering at the SQL layer are
> pre-requisites for a clean SELinux implementation, where the only
> difference is that the permission checks are handled by asking SELinux
> instead of looking in the catalog.
That strikes me as an approach more likely to be fruitful.
I get the point about imposing all the restrictions at the SELinux
layer. But the way to do that, I think, is to make the individual
policies possible to implement in PostgreSQL simpliciter, and then
have some interface to the SELinux permissions system so that it
becomes possible to set those definitions outside Postgres. (I know
that the latter raises all sorts of nasty DoS scenarios. That's
clearly one of the problems that will need addressing.)
Again, I support the effort in principle; I'm just not sure that the
current proof-of-concept work is what will be needed to address the
design goals. I do think that somewhat clearer scope definitions
would be a big help in deciding which modifications are really needed,
and where.
A
--
Andrew Sullivan
ajs@commandprompt.com
+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
No comments:
Post a Comment