Jaime Casanova wrote:
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?
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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
