Re: [idea] a copied relkind in pg_attribute

Jaime Casanova wrote:
> 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?

There are various kind of permission in the security policy.
When someone tries to change pg_attribute.attkind, he should have
db_column:{relabelfrom} privilege, because it makes changes to
its object class which is a part of security attribute.
However, when someone tries to change pg_attribute.attnotnull,
he should have db_column:{setattr}, because this operation does not
make changes in its security attribute.
In this case, db_column:{setattr} should be allowed to the client
who connected as a superuser, but db_column:{relabelfrom} should
not be allowed.

If you are not familiar to SELinux, please consider differences
between file ownership and 'w' permission on UNIX filesystem.

> protecting a DBA (DataBase Aniquilator) from shooting himself> on the foot in situations like this one is not a good
approach,IMHO...
 

It is not an issue the "attkind" tries to resolve.

If its object class (part of security attribute) is determined by external
factors, we have to lookup the external factors for each pg_attribute, and
we also have to check permissions on referrer side on changes in external
factors fundamentally.
It is a costly operatin, despite the factor ("relkind") is almost constant.

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

I wanted to introduce it is a strange behavior that same object is
handled as another sort of one depending on external factors.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>