On Thu, Mar 3, 2011 at 5:38 AM, Kohei Kaigai kohei.kai...@eu.nec.com wrote:
BTW, it seems to me the base version of selinux-policy-* package in Ubuntu
is forked from an older snapshot (20091117), so it does not have enough rules
to run SE-PostgreSQL.
Right now, Fedora 13/14 is the easiest
; Andrew Dunstan; Stephen Frost; KaiGai Kohei; PgHacker
Subject: Re: [HACKERS] sepgsql contrib module
On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai kohei.kai...@eu.nec.com
wrote:
The attached patch removes rules to build a policy package for regression
test and modifies documentation part
On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai kohei.kai...@eu.nec.com wrote:
The attached patch removes rules to build a policy package for regression
test and modifies documentation part to introduce steps to run the test.
Committed. Incidentally, on my Ubuntu system:
$ find
February 2011 18:27
To: 'Robert Haas'; Tom Lane
Cc: Andrew Dunstan; Stephen Frost; KaiGai Kohei; PgHacker
Subject: RE: [HACKERS] sepgsql contrib module
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: 15 February 2011 16:52
To: Tom Lane
Cc: Andrew
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build phase. It ought to be generated
during regression test startup, instead.
You have to manually install and enable it
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lanet...@sss.pgh.pa.us wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build phase. It ought to be generated
during regression test startup, instead.
On Tue, Feb 15, 2011 at 10:50 AM, Andrew Dunstan and...@dunslane.net wrote:
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lanet...@sss.pgh.pa.us wrote:
On the whole, I don't think that sepgsql-regtest.pp should be built or
installed at all during the build
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
have to build it first, then install it, then run the regression
tests. It could be a separate target, like 'make
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
have to build it first, then install it, then
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
have
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Those are good points. My point was just that you can't actually
build
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: 15 February 2011 16:52
To: Tom Lane
Cc: Andrew Dunstan; Kohei Kaigai; Stephen Frost; KaiGai Kohei; PgHacker
Subject: Re: [HACKERS] sepgsql contrib module
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane t
Kohei
Cc: KaiGai Kohei; PgHacker
Subject: Re: [HACKERS] sepgsql contrib module
On Wed, Feb 2, 2011 at 11:43 PM, Robert Haas robertmh...@gmail.com wrote:
Committed.
I did some more polishing of the documentation as well.
It would be good to have some buildfarm coverage of this code. Can we
KaiGai,
* Kohei Kaigai (kohei.kai...@eu.nec.com) wrote:
It would be good to have some buildfarm coverage of this code. Can we
find anyone brave enough to set up a buildfarm critter using
--with-selinux?
Although I don't have an account on the buildfarm, I'll set up an environment
for
Cc: Robert Haas; KaiGai Kohei; PgHacker
Subject: Re: [HACKERS] sepgsql contrib module
KaiGai,
* Kohei Kaigai (kohei.kai...@eu.nec.com) wrote:
It would be good to have some buildfarm coverage of this code. Can
we find anyone brave enough to set up a buildfarm critter using
Excerpts from Kohei Kaigai's message of lun feb 14 13:47:58 -0300 2011:
We really need to get a buildfarm which is building with this. To that
end, would you mind providing directions so someone else could set up a
buildfarm member to test it..?
It seems to me not difficult to describe a
On 02/14/2011 11:47 AM, Kohei Kaigai wrote:
We really need to get a buildfarm which is building with this. To that
end, would you mind providing directions so someone else could set up a
buildfarm member to test it..?
It seems to me not difficult to describe a direction to build, install and
Andrew Dunstan and...@dunslane.net writes:
Thew makefile still has this bogosity:
sepgsql-regtest.pp: sepgsql-regtest.te
$(MAKE) -f $(DESTDIR)/usr/share/selinux/devel/Makefile $@
We need to fix that up before we even think of trying to get buildfarm
coverage. The presence and
On 02/14/2011 04:21 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Thew makefile still has this bogosity:
sepgsql-regtest.pp: sepgsql-regtest.te
$(MAKE) -f $(DESTDIR)/usr/share/selinux/devel/Makefile $@
We need to fix that up before we even think of trying to
Andrew Dunstan and...@dunslane.net writes:
Yeah. The next thing I hit was this:
[andrew@aurelia sepgsql]$ make -f /usr/share/selinux/devel/Makefile
sepgsql-regtest.pp
cat: /selinux/mls: No such file or directory
make: *** No rule to make target `sepgsql-regtest.pp'. Stop.
On 02/14/2011 08:36 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Yeah. The next thing I hit was this:
[andrew@aurelia sepgsql]$ make -f /usr/share/selinux/devel/Makefile
sepgsql-regtest.pp
cat: /selinux/mls: No such file or directory
make: *** No rule to
Andrew Dunstan and...@dunslane.net writes:
On 02/14/2011 08:36 PM, Tom Lane wrote:
It looks to me like /selinux/mls is some weird phony-filesystem file,
because cat prints one character (a 1) while ls claims the file is
of zero length. So it's probably something consed up by the kernel,
like
2011/1/27 KaiGai Kohei kai...@ak.jp.nec.com:
(2011/01/27 22:26), Robert Haas wrote:
2011/1/27 KaiGai Koheikai...@ak.jp.nec.com:
- Error messages become obtaining %m, when the error was
originated from the libselinux interfaces. It will provides
DBA a hint why interactions with SELinux
On Wed, Feb 2, 2011 at 11:43 PM, Robert Haas robertmh...@gmail.com wrote:
Committed.
I did some more polishing of the documentation as well.
It would be good to have some buildfarm coverage of this code. Can we
find anyone brave enough to set up a buildfarm critter using
--with-selinux?
--
2011/1/27 KaiGai Kohei kai...@ak.jp.nec.com:
- Error messages become obtaining %m, when the error was
originated from the libselinux interfaces. It will provides
DBA a hint why interactions with SELinux does not work well.
No space before the : %m, please.
Also this word looks like a typo:
(2011/01/27 22:26), Robert Haas wrote:
2011/1/27 KaiGai Koheikai...@ak.jp.nec.com:
- Error messages become obtaining %m, when the error was
originated from the libselinux interfaces. It will provides
DBA a hint why interactions with SELinux does not work well.
No space before the : %m,
2011/1/25 KaiGai Kohei kai...@ak.jp.nec.com:
(2011/01/26 12:23), KaiGai Kohei wrote:
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need some calls to quote_literal_cstr() in there
someplace.
Are you concerning about the object name being supplied to
(2011/01/27 0:25), Robert Haas wrote:
2011/1/25 KaiGai Koheikai...@ak.jp.nec.com:
(2011/01/26 12:23), KaiGai Kohei wrote:
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need some calls to quote_literal_cstr() in there
someplace.
Are you concerning
(2011/01/24 12:49), Robert Haas wrote:
On Sun, Jan 23, 2011 at 9:56 PM, Robert Haasrobertmh...@gmail.com wrote:
On Sun, Jan 23, 2011 at 8:53 PM, Robert Haasrobertmh...@gmail.com wrote:
2011/1/21 KaiGai Koheikai...@ak.jp.nec.com:
The attached patch is a revised version.
I've committed this.
(2011/01/26 12:23), KaiGai Kohei wrote:
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need some calls to quote_literal_cstr() in there
someplace.
Are you concerning about the object name being supplied to
selabel_lookup_raw() in
On Sun, Jan 23, 2011 at 03:19, Robert Haas robertmh...@gmail.com wrote:
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
Do we have any workaround to avoid these indenting/formatting?
Or, the reformatted code is better than before?
That's pretty horrendous. Tom/Bruce, any ideas?
I saw some
Magnus Hagander mag...@hagander.net writes:
On Sun, Jan 23, 2011 at 03:19, Robert Haas robertmh...@gmail.com wrote:
That's pretty horrendous. Tom/Bruce, any ideas?
I saw some similar things earlier, and it turned out to be two
different reasons in two different cases. In one case, it was
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is a revised version.
I've committed this. Cleanup coming...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas robertmh...@gmail.com wrote:
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is a revised version.
I've committed this. Cleanup coming...
Yikes. On further examination, exec_object_restorecon() is pretty
bogus. Surely you need
On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas robertmh...@gmail.com wrote:
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is a revised version.
I've committed this. Cleanup coming...
Yikes. On
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
Do we have any workaround to avoid these indenting/formatting?
Or, the reformatted code is better than before?
That's pretty horrendous. Tom/Bruce, any ideas?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
2011/1/21 KaiGai Kohei kai...@ak.jp.nec.com:
- Add checks to avoid inlining function without db_procedure:{execute}
permission. Sorry, process:{transition} shall be checked in other place.
Hrm. What happens if permissions change between plan time and execution time?
For that matter, I wonder
Robert Haas robertmh...@gmail.com writes:
For that matter, I wonder what happens with regular function
permissions. If the plan inlines the function and then somebody goes
and changes the permission on the function and makes it SECURITY
DEFINER, what happens?
ALTER FUNCTION is supposed to
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
For that matter, I wonder what happens with regular function
permissions. If the plan inlines the function and then somebody goes
and changes the permission on the function and makes
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER FUNCTION is supposed to cause plan invalidation in such a case.
Not sure if GRANT plays nice with that though.
And in the case of SE-Linux, this could get changed from outside
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER FUNCTION is supposed to cause plan invalidation in such a case.
Not sure if GRANT plays nice with that
2011/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
ALTER FUNCTION is supposed to cause plan invalidation in such a case.
On Fri, Jan 21, 2011 at 11:00 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us
2011/1/22 Robert Haas robertmh...@gmail.com:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
For that matter, I wonder what happens with regular function
permissions. If the plan inlines the function and then somebody goes
and
Robert Haas robertmh...@gmail.com writes:
I don't want to go there, and it's not what Tom was proposing anyway.
The idea is - if the user creates a function which is NOT a trusted
procedure and executes it, and then subsequently changes the system
security policy so that it becomes a trusted
Excerpts from Robert Haas's message of jue ene 20 00:10:55 -0300 2011:
You have to write it with a line of dashes on the first and last
lines, if you don't want it reformatted as a paragraph. It might be
worth actually running pgindent over contrib/selinux and then check
over the results.
On Thu, Jan 20, 2011 at 9:59 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of jue ene 20 00:10:55 -0300 2011:
You have to write it with a line of dashes on the first and last
lines, if you don't want it reformatted as a paragraph. It might be
worth
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, I don't think pgindent is run regularly on contrib as it is on the
core code.
News to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
2011/1/5 KaiGai Kohei kai...@ak.jp.nec.com:
How about feasibility to merge this 4KL chunks during the rest of
45 days? I think we should decide this general direction at first.
I read through this code tonight and it looks pretty straightforward.
I don't see much reason not to accept this more
(2011/01/20 12:10), Robert Haas wrote:
2011/1/5 KaiGai Koheikai...@ak.jp.nec.com:
How about feasibility to merge this 4KL chunks during the rest of
45 days? I think we should decide this general direction at first.
I read through this code tonight and it looks pretty straightforward.
I
2011/1/19 KaiGai Kohei kai...@ak.jp.nec.com:
And how about adding a
ProcessUtility_hook to trap evil non-DML statements that some
nefarious user might issues?
It seems to me reasonable as long as the number of controlled command
are limited. For example, LOAD command may be a candidate
(2011/01/20 13:01), Robert Haas wrote:
2011/1/19 KaiGai Koheikai...@ak.jp.nec.com:
And how about adding a
ProcessUtility_hook to trap evil non-DML statements that some
nefarious user might issues?
It seems to me reasonable as long as the number of controlled command
are limited. For
I also think wiki page allows us to brush up the documentation
rather than exchanging patches effectively. I'll set up a wiki page
that contains same contents with *.sgml file to revise documentation
stuff to be included into the *.sgml file finally. How about this idea?
Sounds good.
I set
2011/1/6 KaiGai Kohei kai...@ak.jp.nec.com:
1. Why is sepgsql the right name for this module, as opposed to, say,
selinux? We don't call the cube module cubepgsql, or the hstore
module hstorepgsql. Maybe there's a reason why this case is
different, but I'm not sure.
In some previous cases
2. The docs contains some references to /usr/local/pgsql/share.. Does
this really mean whatever sharedir you established when you ran
configure, i.e. the output of pg_config --sharedir? I hope so.
Yes, it means the sharedir being configured.
I found the following description at the
2011/1/6 KaiGai Kohei kai...@ak.jp.nec.com:
If we use result of the `pg_config --sharedir` here, how about this
writing style? Or, do we have any other ideas?
I'm not sure - I'll look at your next draft more closely.
The background of this wikipage is that I was persuading people
this
2011/1/5 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is the modular version of SE-PostgreSQL (take.2).
I'm reading through the documentation and so far it looks pretty
reasonable. But I have some questions and suggested changes, of
course. :-)
1. Why is sepgsql the right name for
(2011/01/06 14:28), Robert Haas wrote:
2011/1/5 KaiGai Koheikai...@ak.jp.nec.com:
The attached patch is the modular version of SE-PostgreSQL (take.2).
I'm reading through the documentation and so far it looks pretty
reasonable. But I have some questions and suggested changes, of
course.
(2010/12/27 17:53), Simon Riggs wrote:
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly.
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become visible.
But no matter. Since only
(2010/12/30 9:34), Simon Riggs wrote:
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly.
I think we need a Guide to Security
(2010/12/24 11:53), KaiGai Kohei wrote:
There is one another issue to be discussed.
We need a special form of regression test. Because SE-PostgreSQL
makes access control decision based on security label of the peer
process, we need to switch psql process during regression test.
(So, I don't
63 matches
Mail list logo
