2012/3/20 Robert Haas robertmh...@gmail.com:
On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga yebhavi...@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
On Wed, Mar 21, 2012 at 6:07 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The reason why dynamic domain transition should be configured
carefully is that it partially allows users to switch their own privileges
in discretionary way, unlike trusted procedure.
The original model of selinux on
On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga yebhavi...@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
On 2012-03-15 21:45, Robert Haas wrote:
On Wed, Mar 14, 2012 at 11:10 AM, Kohei KaiGaikai...@kaigai.gr.jp wrote:
If it is ready to commit, please remember the credit to Yeb's volunteer
on this patch.
Done.
In the patch with copy-editing documentation following that commit, at
in at their
On Wed, Mar 14, 2012 at 11:10 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
If it is ready to commit, please remember the credit to Yeb's volunteer
on this patch.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Suppose that the connection starts out in context connection_pooler_t.
Based on the identity of the user, we transition to foo_t, bar_t, or
baz_t. If it's possible, by any
2012/3/9 Robert Haas robertmh...@gmail.com:
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai kai...@kaigai.gr.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
2012/3/11 Yeb Havinga yebhavi...@gmail.com:
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with added
documentation.
Thanks for your dedicated volunteer. I'm under checking of the updates
at
On Sat, Mar 10, 2012 at 4:35 PM, Yeb Havinga yebhavi...@gmail.com wrote:
The semantics are muddled because the client labels are mixed with labels
from trusted procedures. The stack you described upthread may also exhibit
surprising behaviour. If a trusted procedure is called, it's label is
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a practical reason. In case when httpd open the connection to PG and
set a suitable security label according to the given credential prior to
launch
of user application, then keep this connection for upcoming
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a practical reason. In case when httpd open the connection to PG and
set a suitable security label according to the given credential prior to
launch
of user
On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a practical reason. In case when httpd open the connection to PG and
set a suitable security
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 11:13 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/3/12 Robert Haas robertmh...@gmail.com:
On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is a practical reason. In case when httpd open the
On Mon, Mar 12, 2012 at 12:30 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Suppose that the connection starts out in context connection_pooler_t.
Based on the identity of the user, we transition to foo_t, bar_t, or
baz_t. If it's possible, by any method, for one of those contexts to
get back
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with added
documentation.
Some other notes.
- Robert asked why sepgsql_setcon with NULL to reset the value to the
initial client label was supported.
On 2012-03-11 11:33, Yeb Havinga wrote:
On 2012-03-10 10:39, I wrote:
I can probably write some docs tomorrow.
Attached is v5 of the patch, with is exactly equal to v4 but with
added documentation.
s/literalcube(1) == '(1)'/literal// in that patch please
--
Sent via pgsql-hackers
On 2012-03-09 21:49, Robert Haas wrote:
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGaikai...@kaigai.gr.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
On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havinga yebhavi...@gmail.com wrote:
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
On 2012-03-10 14:06, Robert Haas wrote:
On Sat, Mar 10, 2012 at 4:39 AM, Yeb Havingayebhavi...@gmail.com wrote:
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
On 2012-03-06 15:14, Kohei KaiGai wrote:
In case of sepgsql_setcon() being invoked with null argument
to reset security label of the client, but not committed yet,
the last item of the client_label_pending has null label.
(It performs as a mark of a security label being reset.)
Yes, I see that
On Tue, Mar 6, 2012 at 9:14 AM, Kohei KaiGai kai...@kaigai.gr.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
Hi, Yeb.
Thanks for your reviewing and patch updates.
(and sorry my delayed response...)
I'd like to point out a case when plabel-label is NULL.
In case of sepgsql_setcon() being invoked with null argument
to reset security label of the client, but not committed yet,
the last item of the
On 2012-02-24 17:25, Yeb Havinga wrote:
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havingayebhavi...@gmail.com:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to
label.c
because of references to static variables. The part-2
2012/2/24 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-24 15:17, Yeb Havinga wrote:
I don't know what's fishy about the mgrid user and root that causes
c0.c1023 to be absent.
more info:
In shells started in a x environment under Xvnc, id -Z shows the system_u
and c0.c1023 absent.
In
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havingayebhavi...@gmail.com:
So maybe this is because my start domain is not s0-s0:c0.c1023
However, when trying to run bash or psql in domain
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 I get permission
denied.
Distribution is
2012/2/24 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havingayebhavi...@gmail.com:
So maybe this is because my start domain is not s0-s0:c0.c1023
However, when trying to run bash or psql in domain
On 2012-02-24 14:20, Kohei KaiGai wrote:
It seems to me you try to expand categories of the client.
The log saids sepgsql_setcon() tries to switch to ...:s0:c0.c15 from ...:s0.
It is not an admitted operations because of increasion of categories.
Yes I had my eye on the missing c0.c1023
On 2012-02-24 15:17, Yeb Havinga wrote:
I don't know what's fishy about the mgrid user and root that causes
c0.c1023 to be absent.
more info:
In shells started in a x environment under Xvnc, id -Z shows the
system_u and c0.c1023 absent.
In shells started from the ssh daemon, the id -Z
On 2012-02-23 12:17, Kohei KaiGai wrote:
2012/2/20 Yeb Havingayebhavi...@gmail.com:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to label.c
because of references to static variables. The part-2 patch implements above
mechanism.
I took
2012/2/20 Yeb Havinga yebhavi...@gmail.com:
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to label.c
because of references to static variables. The part-2 patch implements above
mechanism.
I took a short look at this patch but am
On 2012-02-05 10:09, Kohei KaiGai wrote:
The attached part-1 patch moves related routines from hooks.c to
label.c because of references to static variables. The part-2 patch
implements above mechanism.
I took a short look at this patch but am stuck getting the regression
test to run
On Sun, Feb 5, 2012 at 4:09 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached part-1 patch moves related routines from hooks.c to
label.c because of references to static variables.
I have committed this part. Seems like a better location for that code, anyhow.
--
Robert Haas
Kevin Grittner wrote:
Tom Lane wrote:
I agree it's a bug that you can do what Kevin's example shows.
I'll look at it and see if I can pull together a patch.
Attached.
Basically, if a GUC has a check function, this patch causes it to be
run on a RESET just like it is on a SET, to make
Tom Lane wrote:
More to the point, a GUC rollback transition *has to always
succeed*. Period.
I was about to point out the exception of the transaction_read_only
GUC, which according to the standard must not be changed except at
the beginning of a transaction or a subtransaction, and must
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane wrote:
More to the point, a GUC rollback transition *has to always
succeed*. Period.
[ counterexample showing we should sometimes disallow RESET ]
This actually isn't what I was talking about: a RESET statement is a
commanded
Tom Lane wrote:
What I was concerned about was the case where GUC is trying to
re-establish an old value during transaction rollback. For example,
assume we are superuser to start with, and we do
begin;
set role unprivileged_user;
...
rollback;
The rollback needs to
On 2012-01-30 19:19, Robert Haas wrote:
On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGaikai...@kaigai.gr.jp wrote:
However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga yebhavi...@gmail.com wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to succeed. This would also be useful in
On 2012-01-31 14:06, Robert Haas wrote:
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havingayebhavi...@gmail.com wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to
On Tue, Jan 31, 2012 at 9:10 AM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2012-01-31 14:06, Robert Haas wrote:
On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havingayebhavi...@gmail.com wrote:
What about always allowing a transition to the default / postgresql.conf
configured client label, so in the
On 2012-01-31 15:28, Robert Haas wrote:
*scratches head*
I'm not sure I follow you. If you're saying that we can make this
work by always allowing the value to be reset, then I agree with you,
but I'm not sure those are the semantics KaiGai wants. For instance,
if a connection pooler does:
Robert Haas robertmh...@gmail.com writes:
and that's bad. More generally, the system security policy is
designed to answer questions about whether it's OK to transition from
A-B, and the fact that A-B is OK does not mean that B-A is OK, but
our GUC mechanism pretty much forces you to
On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/28 Kohei KaiGai kai...@kaigai.gr.jp:
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering
2012/1/28 Kohei KaiGai kai...@kaigai.gr.jp:
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can
2012/1/26 Robert Haas robertmh...@gmail.com:
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC
On Tue, Jan 10, 2012 at 6:28 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
This patch adds a new GUC sepgsql.client_label that allows client
process to switch its privileges into another one, as long as the
system security policy admits this transition.
Because of this feature, I ported two
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that. I think. But if you expose a
On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/1/26 Robert Haas robertmh...@gmail.com:
I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a
48 matches
Mail list logo
