Re: [v9.1] sepgsql - userspace access vector cache - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.1] sepgsql - userspace access vector cache
Date
Msg-id CA+TgmoYdtf5TsSEffi_DEpaZj3JQMtmygCJ+GwC1ntkNoHJXyQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.1] sepgsql - userspace access vector cache  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.1] sepgsql - userspace access vector cache
List pgsql-hackers
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> BTW, what is the current status of this patch?
> The status of contrib/sepgsql part is unclear for me, although we agreed that
> syscache is suitable mechanism for security labels.

Sorry it's taken me a while to get around to looking at this.  Reviewing away...

For me, the line you removed from dml.out causes the regression tests to fail.

I don't understand what this is going for:

+       /*
+        * To boost up trusted procedure checks on db_procedure object
+        * class, we also confirm the decision when user calls a procedure
+        * labeled as 'tcontext'.
+        */

Can you explain?

sepgsql_avc_check_perms_label has a formatting error on the line that
says "result = false".  It's not indented correctly.

Several functions do this: sepgsql_avc_check_valid(); do { ... } while
(!sepgsql_avc_check_valid);  I don't understand why we need a loop
there.

The comment for sepgql_avc_check_perms_label uses the word "elsewhere"
when it really means "otherwise".

Changing the calling sequence of sepgsql_get_label() would perhaps be
better separated out into its own patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Jesper Krogh
Date:
Subject: tsvector concatenation - backend crash
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] pg_upgrade problem