Re: [v9.2] Add GUC sepgsql.client_label - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.2] Add GUC sepgsql.client_label
Date
Msg-id CA+TgmoZJujHFsyqj1TTx=rb4=3e=-sd-=vRDOuk_C4+FMh=F9A@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] Add GUC sepgsql.client_label  (Yeb Havinga <yebhavinga@gmail.com>)
Responses Re: [v9.2] Add GUC sepgsql.client_label
List pgsql-hackers
On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga <yebhavinga@gmail.com> wrote:
> In the patch with copy-editing documentation following that commit, at "in
> at their option", s/in// ?

Oh, yeah.  Oops.  Thanks.

> Also 'rather than .. as mandated by the system':
> I'm having trouble parsing 'as'. It is also unclear to me what 'system'
> means: selinux or PostgreSQL, or both? I suspect it is PostgreSQL, since
> selinux is still enforcing / 'mandating' it's policy. What about "rather
> than that the switch is controlled by the PostgreSQL server, as in the case
> of a trusted procedure."

Well, I think it's both.  PostgreSQL is responsible for enforcing
privileges on database objects, but it relies on SE-Linux to tell it
whether a given access is allowable.  So, from PostgreSQL's point of
view, it's delegating the decision to SE-Linux.  But SE-Linux views
itself as a mechanism for enforcing a system-wide security policy, so
views PostgreSQL as an instrument for carrying out its access control
goals.  I don't know how to disentangle that.  I'm actually not
entirely sure that I even believe the underlying sentiment that
dynamic transitions are dangerous.  Maybe KaiGai could comment further
on what we should be trying to convey here.

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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Regarding column reordering project for GSoc 2012
Next
From: Robert Haas
Date:
Subject: Re: Proposal: Create index on foreign table