From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | Yeb Havinga <yebhavinga(at)gmail(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <jbrindle(at)tresys(dot)com> |
Subject: | Re: [v9.2] Add GUC sepgsql.client_label |
Date: | 2012-03-09 20:49:55 |
Message-ID: | CA+TgmobD-gu8izi320cn3FBQ=dS22ZGnAfm8SSJVkfkjDVgBNQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> [ new patch ]
Are we absolutely certain that we want the semantics of
sepgsql_setcon() to be transactional? Because if we made them
non-transactional, this would be a whole lot simpler, and it would
still meet the originally proposed use case, which is to allow the
security context of a connection to be changed on a one-time basis
before handing it off to a client application.
As a separate but related note, the label management here seems to be
excessively complicated. In particular, it seems to me that the
semantics of sepgsql_get_client_label() become quite muddled under
this patch. An explicitly-set label overrides the default label, but
a trusted procedure's temporary label overrides that. So if you enter
a trusted procedure, and it calls sepgsql_setcon(), it'll change the
label, but no actual security transition will occur; then, when you
exit the trusted procedure, you'll get the new label in place of
whatever the caller had before. That seems like one heck of a
surprising set of semantics.
It seems to me that it would make more sense to view the set of
security labels in effect as a stack. When we enter a trusted
procedure, it pushes a new label on the stack; when we exit a trusted
procedure, it pops the top label off the stack. sepgsql_setcon()
changes the top label on the stack. If we want to retain
transactional semantics, then you can also have a toplevel label that
doesn't participate in the stack; a commit copies the sole item on the
stack into the toplevel label, and transaction start copies the
toplevel label into an empty stack. In the current coding, I think
client_label_peer is redundant with client_label_committed - once the
latter is set, the former is unused, IIUC - and what I'm proposing is
that client_label_func shouldn't be separate, but rather should mutate
the stack of labels maintained by client_label_pending.
The docs need updating, both to reflect the version bump in
sepgsql-regtest.te and to describe the actual feature.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-03-09 20:54:30 | Re: poll: CHECK TRIGGER? |
Previous Message | Dimitri Fontaine | 2012-03-09 20:40:31 | Re: Is it time for triage on the open patches? |