On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
> > I'm starting to think that there's just no hope of this matching up
> > well enough with the way PostgreSQL already works to have a chance of
> > being accepted.
>
> What I'm understanding here is the apparent requirement that the SEPostgreSQL
> implementation be done in a way that a generic SELinux policy that has been
> written for an operating system and file system can be applied to PostgreSQL
> without change and do something useful. I can see merits for or against that.
> But in any case, this needs to be clarified, if I understand this requirement
> correctly anyway.
Indeed. My impression was also that there are existing SELinux rules
and permission concepts already in use and people would like to apply
them to PostgreSQL, which puts the translation layer inside postgres.
However, from the postgres side there appears to be a push to make
unique postgresql SELinux rules and requiring every user of SELinux to
do the mapping of rights to postgresql specific terms.
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.
Personally I find the idea that SELinux permissions need to meet parity
with the existing permission structure crazy, since it's not going to
replace the existing permissions, just supplement them.
Merely my opinion ofcourse, which doesn't count for much :)
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.