On Wed, Dec 24, 2008 at 7:05 PM, KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
>
> The other need an explanation. A database superuser is allowed
> to update system catalog by hand, if it is allowed by the security
> policy. For example, he will be able to update "relkind" in some
> of pg_class, even if it never happen in general DDLs.
> If a "relkind" is changed from 'r' to 'c', we deal pg_attribute
> entries pointing the tuple as db_tuple class, not db_column class,
> because they are not already columns.
> It means we fundamentally have to check permissions on pg_attribute
> when pg_class is updated, or pg_attribute should have its identifier
> information. I think the later approach is more simple.
>
and what stops a superuser (if it's allowed by the security policy)
from changing pg_attribute.attkind? protecting a DBA (DataBase
Aniquilator) from shooting himself on the foot in situations like this
one is not a good approach, IMHO...
> Please consider an another instance. In filesystem, 'x' permission
> bit has different meaning between files and directries. If a derectory
> without no child files is handled as a regular file suddenly, it can
> make a confusion. It is a similar situation.
>
doesn't understand this...
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157