On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> I don't think it is an option to move the hook after the pollution
> of system catalogs, although we can pull out any information about
> the new relation from syscache.
Why not?
> Sorry, it seems to me the idea simplifies the issue too much to implement
> access control features correctly.
> For example, we need to provide security modules the supplied label on
> the SECURITY LABEL hook, so it has to take one more argument at least.
> For example, we will need to provide them OID of the new schema on
> the ALTER TABLE SET SCHEMA at least too.
> :
So what? The patch you submitted doesn't provide the OID of the new
schema when someone does ALTER TABLE SET SCHEMA, either. I proposed a
design which was much more general than what you submitted, and you're
now complaining that it's not general enough. It's unrealistic to
think you're going to solve every problem with one patch. Moreover,
it's far from obvious that you actually do need the details that
you're proposing anyway. Are you really going to write an SE-Linux
policy that allows people to change the schema of table A to schema B
but not schema C? Or that allows a hypothetical smack plugin to label
a given object with one label but not another? And if so, are those
absolutely must-have features for the first version or are those
things that would be nice to have in version 3 or 4?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
