On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley <dpqu...@tycho.nsa.gov> wrote: > The main concern I hear is that people are worried that this is an > SELinux specific design. I heard at the meeting on Wednesday that the > Trusted Extensions people looked at the framework and said it meets > their needs as well. If thats the case where does the concept that the > design is SELinux specific stem from? We've asked Casey Schaufler the > developer of another label based MAC system for Linux to look at the > hooks as well and make a statement about their usability.
OK, on second thought I want to address this a little more, since some of these concerns came from me. SE-Linux-specific may be the wrong way to say it. There's an old saying that goes something like: if a function has 10 parameters, it has 11 parameters. In other words, if you're passing too much information across a supposed abstraction boundary, it's not really an abstraction boundary at all. If we design a security abstraction layer, the interfaces need to really be abstraction boundaries. Passing the table OID and then also the tablespace OID because PG DAC needs that to make its access control decision is crap. As soon as some other security model comes along you will need to add additional arguments for all of the things that the new security model cares about, and when a third security model comes along you will need to pass those things now too. If we're doing that sort of thing, we might as well leave the entire jumble of spaghetti code in its original location so that at least you don't have to flip back and forth between two different source files. And if we're going to do that, we might as well quit now because our heads will explode (Tom's first). I actually have an idea how to solve the problem in this particular case, but I'm reluctant to say what it is because I'm not sure if I'm right, and at any rate *I don't want to write this patch*. I may review it and if it's good I may commit it (or more likely a more extensive version of it after we have agreement on the basic principles) but I don't to want to write it or do substantial cleanup of it. I have my own list of things to work on and I presently have no reason to put this on that list. As a community, I think that at times we have a tendency to say "well, the committer is just going to rewrite this anyway, so it doesn't really matter what we do". As far as I am concerned that is flat false. I do not want to rewrite your patch. I want to look at your patch, convince myself that it is correct, and commit it. That won't always happen, and I'm certainly willing to do more than that especially in cases where it's a feature that I really care about, but AFAIAC the initiative is with the patch author to provide something committable, NOT with the committer to fix what the patch author did wrong. I realize that's subjective at times, and I'm going to make my best effort not to be a jerk about it, but given that there are only so many hours in the day (and not all of the can be spent on PostgreSQL) I think that's the goal we need to shoot for. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
