Re: [v9.1] sepgsql - userspace access vector cache

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Kohei Kaigai <Kohei(dot)Kaigai(at)emea(dot)nec(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Yeb Havinga <yebhavinga(at)gmail(dot)com>
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Date: 2011-08-25 20:17:40
Message-ID: CA+TgmoYdtf5TsSEffi_DEpaZj3JQMtmygCJ+GwC1ntkNoHJXyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-08-25 20:33:07 Re: [GENERAL] pg_upgrade problem
Previous Message hubert depesz lubaczewski 2011-08-25 19:57:58 pg_upgrade problem