Bruce Momjian wrote:
>> At least, we cannot apply this scheme on the next phase (row-level)
>> due to the storage consumption and others. So, I don't think it is
>> a preferable way to design the first step without ignoring upcoming
>> expandability.
>
> The big problem is that the security value on system tables controls the
> _object_ represented by the row, while on user tables the security value
> represents access to the row. That is just an odd design, and why a
> regular system table security value makes sense, independent of the
> row-level security feature.
I don't think there is a fundamental differences between "ALTER FUNCTION"
and "UPDATE pg_proc SET ...", for example. It is necessary to apply
same privileges in this case.
(In this case, db_procedure:{setattr} is checked on the object.)
The security label of system catalogs (like pg_class, pg_proc, ...) are
also used when the objects are used as target of user's request, like
a target of SELECT statement, a target of function invocation.
Please note that different permissions are checked in this case.
(db_table:{select} and db_procedure:{execute})
Sorry, it is a bit unclear what is a problem you pointed out.
I guessed you concerned about a tuple (within system catalogs) is handled
as an object when user tries to modify the system catalogs by hand.
However, I cannot understand why it is an odd design.
If we keep free to update system catalogs, it makes a bypassable
route to create/alter/drop objects.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
