On Wed, Dec 24, 2008 at 7:05 PM, KaiGai Kohei <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
