Thread: [idea] a copied relkind in pg_attribute

It is an idea to improve the implementation of SE-PostgreSQL.
I need a copied relkind in pg_attribute, to help its decision
making.

When we access on pg_attribute via ALTER TABLE or DML statement
directly, SE-PostgreSQL checks privilleges for the fetched tuples.
If the relation pointed by its attrelid has RELKIND_RELATION,
the fetched tuple is a column, so db_column object class should
be applied. Otherwise, db_tuple object class should be applied,
because it is not a column, like an entity of composite type.

The current implementation need to lookup RELOID system cache to
identify the relkind of the relation, because pg_attribtue does
not have any information about "relkind". However, I also think
it is not an ideal implementation, even if its frequency is enough
small.

So, I have a plan to put a new member named as "attkind" into
pg_attribute to hold a copied value of its "relkind".
It enables to identify the attribute without looking up system
cache, so it is better than current one.
The pg_class.relkind is always unchanged, so it does not have
any problematical point.

Please comment anything, if you have alternative idea or opinions.
If reviewer intend to comment about the point, it can be fixed with
the above way.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

On Wed, Dec 24, 2008 at 6:50 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>
> The current implementation need to lookup RELOID system cache to
> identify the relkind of the relation, because pg_attribtue does
> not have any information about "relkind". However, I also think
> it is not an ideal implementation, even if its frequency is enough
> small.
>

but you still can do it, right?
there are any other advantages, like something you can't do now?
if not, i think you need to probe that there will be any benefit in
speed and that is significant otherwise this seems like premature
optimization and that AFAIR is the root of all evil :)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Jaime Casanova wrote:
> On Wed, Dec 24, 2008 at 6:50 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>> The current implementation need to lookup RELOID system cache to
>> identify the relkind of the relation, because pg_attribtue does
>> not have any information about "relkind". However, I also think
>> it is not an ideal implementation, even if its frequency is enough
>> small.
>>
> 
> but you still can do it, right?
> there are any other advantages, like something you can't do now?

Yes, we still can see "relkind" via system cache.
When we fetch a tuple from pg_attribute, it need to look up the
RELOID system cache to get the relkind of its relation.

The reason why I considered the change is preferable is advantanges
in performance and robustness in security design.

The first one is obvious. If we have "attkind" member, it is not
necessary to look up the RELOID system cache for each tuples.

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.

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.

So, I want to put a needed attribute to identify itself.

Thanks,

> if not, i think you need to probe that there will be any benefit in
> speed and that is significant otherwise this seems like premature
> optimization and that AFAIR is the root of all evil :)

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

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

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>