(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?
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>