Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: How to get SE-PostgreSQL acceptable
Date
Msg-id 49879DB6.90202@ak.jp.nec.com
Whole thread Raw
In response to Re: How to get SE-PostgreSQL acceptable  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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>


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: add_path optimization
Next
From: Bruce Momjian
Date:
Subject: Re: More FOR UPDATE/FOR SHARE problems