Re: security hook on table creation

(2010/09/29 22:00), Robert Haas wrote:
> On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei<kaigai(at)kaigai(dot)gr(dot)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?
>
All the existing security checks applies before modifying system catalogs.

At least, I cannot find out any constructive reason why we try to apply
permission checks on object creation time with different manner towards
the existing privilege mechanism...

>> 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.

Sorry, I never said one patch with enough generic hook solves everything.

By contraries, I think the proposed prototype of the hook cannot inform
the plugins anything except for OID and event type, even if necessary.
Some of permission checks needs its specific prototype to inform extra
information rather than OIDs; such as new label in SECURITY LABEL hook,
new schema in upcoming ALTER TABLE SET SCHEMA, and so on...

Of course, we can implement some of permission checks with OID of the
target object and event type collectly. E,g. I cannot image any extra
information to check permission on COMMENT. I never deny it.

> 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?
>

In your proposition, prototype of the security hook has four arguments:
ObjectType, oid, subid and ObjectAccessType, doesn't it?

When user tries to change the schema of table from A to B, we can know
the current schema of the table using syscache, but we need to inform
the plugin that B is the new schema, because we have no way to pull out
what schema was provided by the user.

As LookupCreationNamespace() checks CREATE permission on the new schema,
SELinux also want to check permission on the new schema, not only old one.
So, I concerned about the prototype does not inform about new schema that
user provided using ALTER TABLE SET SCHEMA statement.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>