KaiGai Kohei wrote: > Heikki Linnakangas wrote: >> KaiGai Kohei wrote: >>> Robert Haas wrote: >>>> 2009/10/27 KaiGai Kohei <kai...@ak.jp.nec.com>: >>>>> - no statement support to specify security context. >>>>> (It makes impossible to add support in pg_dump. Is it really OK?) >>>> I doubt that anything without pg_dump support would be even vaguely OK... >>> In my previous experience, it enabled to reduce 300-400 lines of the patch. >>> But here is no more sense than the 300-400 lines. >>> >>> In my honest, I like to include a feature to specify an explicit security >>> context in the patch from the begining. >>> (It also allows to attach test cases with more variations.) >> Can you explain why that's required for pg_dump support? I was thinking >> that there would be no explicit security labels on objects, and >> permissions would be checked based on other inherent properties of the >> object, like owner, name, schema etc. > > In SELinux model, security context is the only property which can be > used to decision making based on the security policy. > It never uses any other properties, like owner, name, ...
The security context doesn't necessary need to be given explicitly. Things like network ports, files in filesystems that don't support security labels are assigned a security context based on some external policy. Hmm, I guess the whole feature becomes completely pointless if all objects always have their default labels, and can't be changed. So I guess we need that. I think this discussion started when I wondered why we can't put the SE-pgsql check for creating an object (e.g table) into pg_namespace_aclcheck() without changing the signature. The reason you gave is that we need the security context of the new table being created to decide if creating such a table is allowed. But assuming that the new table inherits the security context of the schema it's created in, pg_namespace_aclcheck() *does* have all the necessary information: it knows the namespace which determines the new object's security context. As long as we don't provide syntax to define the security context in the CREATE command, we're fine, even if there's an ALTER command to change the security context of the object after the creation. I'm not sure how much of a difference that detail makes in the big scheme of things, I'm just trying to find ways to make the patch minimally invasive.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
