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 <klep...@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.
signature.asc
Description: Digital signature