Martijn van Oosterhout wrote:
On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote:
Specifically, creating SELinux permissions for CREATE LANGUAGE seems
particularly useless since that's not a data protection issue. The same
with aggregates, operator classes, etc. ISTM the goal of SELinux is not
primarily to restrict DDL but mostly to protect the data.
The reason for comprehensively protecting objects isn't necessarily about
protecting the data in the database but for limiting information flow
between clients of differing security levels. Eg., if someone top secret
can create language and use that to pass information down to someone
unclassified then postgres could be used as an information downgrader
illegitimately.
Consider the pl/pgsql language. The creation of the language must be
protected, because it involves loading shared libraries and thus could
be used to bypass the system. However, once loaded the language only
uses the internal SQL interface and thus is subject to the restrictions
imposed by the caller (except for setuid functions ofcourse).
Would you agree if the language is transparent with respect to
permissions that *usage* of the laguage doesn't need to be restricted.
Using something is typically controlled because of information you may get from
using it (for example, stat() on a file may not get you the data in the file but
it gets you plenty of other information). I guess the question is, can the
person creating the language leak information to people using the language and
it sounds like they can.
However, because language creation is controlled via superuser privilege (which
is never ideal, we like to be able to break superusers up and give them only
permission to do what they need to do, principle of least privilege) then it is
probably a lot less important than many of the other things KaiGai is trying to
get in.
I'm asking because from my position it looks like KaiGai is being
simultaneously told "you patch is too big, make it smaller" and "your
patch is not complete (with respect to some metric), make it bigger"
and we need to define a middle ground if we want to avoid the
appearence of moving goalposts.
Agreed, there are lots of mixed signals in this thread. For my uses the 'basic'
support being pushed won't be enough to use this in secure applications, nothing
less than full row-level access control would be.
I'm all for the community taking smaller patches over time but if there is no
intention of going all the way at the end then I'm not sure what you/we are gaining.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
