Re: security hook on table creation - Mailing list pgsql-hackers

2010/10/17 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> (2010/10/15 22:04), Stephen Frost wrote:
>> KaiGai,
>>
>> * KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
>>> However, it requires the plugin modules need to know everything;
>>> such as what is visible/invisible. It seems to me too closely-
>>> coupled interface.
>>
>> I agree with Robert on this one.  We're not trying to design a wholly
>> independent security module system for any project to pick up and use
>> here.  We're discussing hooks to go into PostgreSQL to support a
>> PostgreSQL security module.  In other words, I don't think we need to
>> worry over if the PG-SELinux security module could be re-used for
>> another project or is too "PG specific".  If it's *not* very PG
>> specific then something is wrong.
>>
>> The issues we're talking about with regard to MVCC, visibility, etc,
>> would all be applicable to any serious database anyway.
>>
> Sorry for this delayed reply, because I've not been internet connectable
> for a couple of days.
>
> What we are always talking about is a PG specific security module, not
> universal ones for any other RDBMS.
>
> Please imagine a scenario that I'm concerning about, as follows:
>
> If and when we will release a minor version up (E.g: 9.1.3 -> 9.1.4)
> which contains hot-fixes around the object creation code and its security
> hook, it may affect MVCC visibility to the guest of the security hook.
> In this (bad) case, the security module would lose compatibility across
> the minor version up. I said it as "security module need to know everything".
> To avoid this, we will need to become paying attention what will be happen
> on the security hooks whenever we apply these bug fixes. So, I'm saying it
> will become a burden of management in the future.
>
> If MVCC visibility always would match with existing permission checks,
> we don't need to pay special attention for these things, do we?

It seems to me that you're worrying about the wrong set of problems.
The original purpose of what I proposed was to let you set a security
context on a new object at creation time, not to provide fine-grained
DDL access control.  I thought perhaps we could kill two birds with
one stone, but if not, let's take three steps back and assume that DDL
permissions will be controlled using a coarse-grained check installed
in ProcessUtility_hook, so that by the time these hooks get installed
they have no job except to apply any necessary label.

But as to your question, nothing whatever excuses you from needing to
worry about MVCC.  The entire backend is littered with things that
have to worry about MVCC.  Whether there's a concern for any
particular bit of code depends heavily on what that code does, but "I
put it in the same place so I needn't worry" is only true if you're
doing the same thing, which you may not be.  Nor is it correct to
suppose that doing permissions checking the way you're proposing is
going to somehow be free of code maintenance concerns.  Indeed, many
of the patches you've submitted in this area have been rejected
precisely because they would make the code quite difficult to maintain
- for example, by passing bits of no obvious relevance to the hooks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company