On Mon, Apr 20, 2009 at 3:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> It seems to me a quite ad-hoc idea. > > That's rather a silly charge to be leveling when your own proposal is > such a horrid kluge as this one. As near as I can tell, you intend > that SELinux will be unable to prohibit SELECT FOR UPDATE because it > cannot tell the difference between that and a foreign key reference. > If that isn't a hack, I don't know what is.
I think we're talking at cross purposes here. I think Kai Gai's descriptions make sense if you start with a different set of assumptions. The idea behind SELinux is that each individual object is access controlled and each user has credentials which grant access to specific operations on specific objects. As I understand it part of the goal is to eliminate situations where "setuid" or other forms of privilege escalation is required. So in this situation -- I suspect, if any SELinux people want to pipe up to tell me whether I'm on the right track -- the idea is that you should be able to examine a user superficially and know for certain whether he has the ability to lock a record or whether that privilege has been denied him. It shouldn't be possible for him to gain the privilege by going through a view or trigger which runs as another user. If that's right then the previous suggestion that we take only the part of SELinux which maps to the existing POstgres model really falls down. SEPostgres won't map to the Postgres model just as SELinux doesn't map directly to the traditional Unix security model. It'll be a whole new security model which may be internally consistent but won't make sense to think about together with the Postgres model. That would be a hard sell because as demonstrated in this thread, we don't really understand the SE security model and it would probably be quite invasive to support. If on the other hand I'm wrong and this isn't a fundamental feature but just an implementation question then I think the right solution is to fix the problems that make it hard to implement the Postgres security model in SELinux. The consensus earlier was that the first version of the patch to land would just be a minimal patch which implements the existing security model using SELinux without making any changes to the model. Playing around with new privileges and how we distinguish referential integrity checks wouldn't be part of that. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers