Review of RLS on inheritance schema HL7 RIM (was Re: Row-security on updatable s.b. views)

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Albana Gaba <a(dot)gaba(at)portavita(dot)eu>, Henk-Jan Meijer <h(dot)j(dot)meijer(at)portavita(dot)eu>
Subject: Review of RLS on inheritance schema HL7 RIM (was Re: Row-security on updatable s.b. views)
Date: 2014-02-07 20:59:19
Message-ID: 52F54927.1040102@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/02/14 15:19, Craig Ringer wrote:
>
> Thanks to the simplified requirements for inheritance, this turns out to
> be fairly easy. There's a version rewritten to use the rewriter in the tag:
>
> rls-9.4-upd-sb-views-v6
>
> on https://github.com/ringerc/postgres.git

Hi Craig, list,

This is review of the current RLS patch on a database schema that uses
inheritance in the 'classical' sense (not partitioning). The review was
done on rls-9.4-upd-sb-views-v4 and hence all comments are about that
version. Comparing output of the minisql script between v4 and v6 gives
differences, as v6 seems to be WIP.

Our goal is to implement the HL7 Reference Information Model (RIM) in
PostgreSQL. A fine-grained access control on the tables would have a
practical use in the context of RIM. So, we have made some preliminary
tests of the Row Security patch for such a specific data model. For the
purpose of reviewing RLS, we have restricted the full RIM to just a few
tables which we call the mini-RIM. It is important to observe that the
RIM uses inheritance, and we use PostgreSQL inheritance to implement the
RIM's inheritance. More details about the RIM are presented below.

In the attached SQL script we list a mini-RIM, along with examples of
RLS enforcement.

General comments about RLS applied on (a minimalistic version of) the
RIM can be summarized as follows:

1. The current RLS implementation works for use cases where
confidentiality attributes are specified in the inheritance root
relation. Since security labelling in the RIM is done on
confidentialitycodes that are present in the inheritance roots (e.g.,
Role and Act), the current RLS works for the RIM.

2. Infinite recursion is well captured in case of recursive restrictions
to tables.

3. RLS syntax is readable and easy to use.

4. Documentation needs work.

5. Subqueries in RLS quals can be pulled up, so opens the ability for
fast processing.

Overall from a users perspective the patch gave a solid impression.

regards,
Yeb Havinga
Albana Gaba
Henk-Jan Meijer

Portavita B.V. The Netherlands

BACKGROUND ON THE REFERENCE INFORMATION MODEL:

To understand how The HL7 Reference Information Model (RIM) uses
PostgreSQL inheritance, it is helpful to understand the meaning of the
content of the parent and child tables. This section describes the
background of the RIM, and describes a few classes of the “Act” hierarchy.

The HL7 RIM[1] is not just yet another information model. It is a
mature, standard information model that has been used and refined over
the course of many years [2][3]. Its purpose is to capture detailed
information for medical records. Pivotal in the RIM is its action-based
modelling, based on ideas that can be traced back to the American
philosopher C.S. Peirce. A direct line from Peirce’s Logic of Relatives
to the foundations of relational databases has been introduced in [4].
Versions of the RIM are now being released as an ANSI standard.

An illustration of the RIM is available at
http://www.healthintersections.com.au/wp-content/uploads/2011/05/RIM.png
The RIM is a set of UML classes, each containing one or more attributes.
The classes are an abstraction of subjects or other concepts that are
relevant within the healthcare domain. To avoid a model with a huge
number of classes, the RIM defines six core classes whereas the vast
majority of the classes are defined as specializations based on the core
ones. The specialization classes inherit all the properties of the
generalization classes while adding specific attributes of its own. To
make matters concrete, let us look at "Act" class.

“Act”: Looking at the right hand side of the RIM illustration referenced
above, we can see the class “Act” and its specializations, and this is
the focal point for the RIM’s action based modeling. Description from
the standard: “Acts are the pivot of the RIM: domain information and
process records are represented primarily in Acts. Any profession or
business, including healthcare, is primarily constituted of intentional
and occasionally non-intentional actions, performed and recorded by
responsible actors. An Act-instance is a record of such an action.”
Notable attributes of “Act” are:

“id” - A unique identifier for the Act. Each Act is associated with a
unique id. All specialization of Act inherit this id. This means that if
there is, for example, an instance of Observation with id 5, there exist
no other acts with id 5. In fact, since technically in the RIM all
identifiers stem from a single infrastructure root, the identifiers are
globally unique: there exists a single object with id 5. This single
object is an instance of Observation, and since Observation is a
specialization of Act, it is also an instance of Act.

“classCode” – The major class of Acts to which an Act-instance belongs.
The allowed codes in classCode form a hierarchical code system. In the
2011 RIM, there are 124 different class codes. This is a larger number
than the number of specializations in the class diagram: only the
classes that need additional properties have their own class definition
in the diagram.

“moodCode” - The intended use of the Act statement: as a report of fact,
a command, a possibility, a goal, etc.

“code” - The particular kind of Act that the Act-instance represents
within its class.

“confidentialityCode” - Codes that identify how sensitive a piece of
information is and/or that indicate how the information may be made
available or disclosed.

Notable specializations of “Act” are “Observation” and
“SubstanceAdministration”.:

“Observation” - The main difference between Observations and other Acts
is that Observations have a value attribute. The code attribute of
Observation and the value attribute of Observation must be considered in
combination to determine the semantics of the observation. Structurally,
many observations are name-value-pairs, where the Observation.code
(inherited from Act) is the name and the Observation.value is the value
of the property. Such a construct is also known as a "variable" (a named
feature that can assume a value); hence, the Observation class is always
used to hold generic name-value-pairs or variables, even though the
variable valuation may not be the result of an elaborate observation
method. It may be a simple answer to a question or it may be an
assertion or setting of a parameter.

“SubstanceAdministration” - A type of procedure that involves a
performer introducing or otherwise applying a material into or to the
subject. Substance administration is distinguished from an exposure by
the participation of a performer in the act. The substance administered
by a performer physically interacts with the subject or is otherwise
"taken in" by the subject during the act of administration. Detailed
information about the supplied substance is represented using the entity
class or one of its subtypes. The performer of a substance
administration may be another entity such as a person, device, plant,
e.g. poison ivy, animal, e.g. mosquito bite, or it may be the same
entity as the subject, as in self-administration. In the intent moods,
substance administration represents the plan to apply a given material.
This includes (but is not limited to) prescriptions in which it might
also be associated with a request for supply. In event mood, substance
administration represents a record of the actual application of a substance.

On the left hand side of the RIM picture we see the “Entity” hierarchy,
with notable specializations “Person” and “Organization. Entities are
linked together in “Roles”: a “Patient” is a specialization of “Role”
where the player is the person that is patient, and the scoper is the
organization where the person is patient. “Roles” can ‘participate’ in
“Acts”. These participations are registered using the “Participation” class.

[1] ‘HL7 Reference Information Model’
http://www.hl7.org/implement/standards/rim.cfm

[2] ‘ Influences of the Unified Service Action Model on the HL7
Reference Information Model.’
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2232835/

[3] History of the HL7 RIM
http://www.ringholm.de/docs/04500_en_History_of_the_HL7_RIM.htm

[4] ‘Charles Peirce’
http://www.newworldencyclopedia.org/entry/Charles_Peirce

Attachment Content-Type Size
mini-rim.sql text/plain 16.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2014-02-07 21:03:22 Re: Changeset Extraction v7.5
Previous Message Thom Brown 2014-02-07 20:58:14 Re: Changeset Extraction v7.5