Sorry for my response being late.
2013/2/26 Joshua Brindle <[email protected]>:
> Kohei KaiGai wrote:
>>
>> Hello,
>>
>> Recent PostgreSQL development newly adds a new feature; materialized
>> view.
>> However, we have no relevant object class in selinux side, so I'd like
>> to add
>> a new db_materialized_view object class to support this object type.
>
>
> Why not just use the db_table object class?
>
Even though the behavior of MV is almost common with table's one,
we will confuse how to control the "refresh" operation.
If we try to adopt "db_table" object class here, we have no relevant
permissions here. I initially thought to abuse "update" permission for
this purpose, however, it was short-sighted solution because it will
make another problem once MV got updatable feature in future
version.
>> Materialized-view allows to construct its result-set to be returned on
>> references
>> by user's query preliminarily, to improve performance to scan multiple
>> tables
>> being combined with complicated joins.
>> In contradiction to its name, its behavior is almost identical with
>> regular tables
>> rather than traditional views. Line SELECT ... INTO command, it saves
>> a snapshot when a particular user (with security label, of course)
>> references
>> the underlying tables onto a regular tables in behalf of MV.
>>
>> In perspective of SELinux, nothings are different from an operation
>> that writes
>> data being read from another tables to a regular table; it should check
>> permission to write on the destination table and to read from the source
>> tables, but materialized-view calls this operation as "refresh".
>>
>
> If a user has the ability to update a table backing an mv, but not the
> refresh permission on the mv, will the mv now be inconsistent?
>
Yes. But MV is originally designed to refresh itself asynchronously
because of performance perspective.
>> The attached patch adds db_materialized_view object class with select,
>> insert, update, delete, lock, refresh and common database permissions.
>> These permissions shall be checked on relevant accesses in manner of
>> what regular table doing, and "refresh" shall be also checked when MV
>> is refreshed.
>>
>
> It seems to me that MV's don't really need to be treated specially. If you
> have access to the backing table/row you'll see it, otherwise you won't.
> Running the query that builds an MV shouldn't yield a different result from
> querying the MV, should it?
>
Even though backing table/row are the only source for the relevant MV,
it may cause a problem when MV and backing tables have different
security label. For example, when MV has "unclassified" and backing
table has "classified" label, is a user with "classified" able to refresh
the MV with source of classified tables. It will allow unclassified users to
reference classified data via MV.
One other problematic scenario is interaction with row-level security
that generates different view depending on user's credential who
refresh the MV. Then, another one may reference the MV being
refreshed with inconsistent credential.
So, these are the reason why I consider MV should has its own
object class to control "refresh" as writer operation, in addition
to insert, update or delete that may be used for the purpose as
literal in the future version.
Thanks,
--
KaiGai Kohei <[email protected]>