nt: 17. Februar 2011 11:42
> To: Kohei Kaigai
> Cc: Tom Lane; Andrew Dunstan; Stephen Frost; KaiGai Kohei; PgHacker
> Subject: Re: [HACKERS] sepgsql contrib module
>
> On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai
> wrote:
> > The attached patch removes rules to build a policy p
On Thu, Mar 3, 2011 at 5:38 AM, Kohei Kaigai 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 way.
Yeah. I think t
011 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:
On Thu, Feb 17, 2011 at 3:56 AM, Kohei Kaigai 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 /usr/share/selinux -name '*ake*'
/usr/
> -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, 20
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
>>> Robert Haas 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
Robert Haas writes:
> On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
>> Robert Haas 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
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
> Robert Haas 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 c
Robert Haas 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 policy', but I don'
On Tue, Feb 15, 2011 at 10:50 AM, Andrew Dunstan wrote:
> On 02/15/2011 10:34 AM, Robert Haas wrote:
>> On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane 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 generate
On 02/15/2011 10:34 AM, Robert Haas wrote:
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane 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
On Mon, Feb 14, 2011 at 9:55 PM, Tom Lane 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 before you can run t
Andrew Dunstan 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 /pro
On 02/14/2011 08:36 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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.
> [andrew@aur
On 02/14/2011 04:21 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 location of thi
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
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 des
16:29
> To: Kohei Kaigai
> 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
> > >
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 environmen
nt: 03 February 2011 05:27
> To: KaiGai Kohei
> Cc: KaiGai Kohei; PgHacker
> Subject: Re: [HACKERS] sepgsql contrib module
>
> On Wed, Feb 2, 2011 at 11:43 PM, Robert Haas wrote:
> > Committed.
>
> I did some more polishing of the documentation as well.
>
> It wou
On Wed, Feb 2, 2011 at 11:43 PM, Robert Haas 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?
--
Robert Haas
Enterprise
2011/1/27 KaiGai Kohei :
> (2011/01/27 22:26), Robert Haas wrote:
>> 2011/1/27 KaiGai Kohei:
>>> - 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 s
(2011/01/27 22:26), Robert Haas wrote:
> 2011/1/27 KaiGai Kohei:
>> - 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.
2011/1/27 KaiGai Kohei :
> - 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: seuciryt
--
(2011/01/27 0:25), Robert Haas wrote:
> 2011/1/25 KaiGai Kohei:
>> (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/1/25 KaiGai Kohei :
> (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
>> se
(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 exec_object
(2011/01/24 12:49), Robert Haas wrote:
> On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas wrote:
>> On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas wrote:
>>> 2011/1/21 KaiGai Kohei:
The attached patch is a revised version.
>>>
>>> I've committed this. Cleanup coming...
>>
>> Yikes. On further ex
On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas wrote:
> On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas wrote:
>> 2011/1/21 KaiGai Kohei :
>>> The attached patch is a revised version.
>>
>> I've committed this. Cleanup coming...
>
> Yikes. On further examination, exec_object_restorecon() is pretty
>
On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas wrote:
> 2011/1/21 KaiGai Kohei :
>> 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 some calls to quote_literal_cstr() in t
2011/1/21 KaiGai Kohei :
> 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 make changes to your s
Magnus Hagander writes:
> On Sun, Jan 23, 2011 at 03:19, Robert Haas 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 because
> I was using GNU indent, even
On Sun, Jan 23, 2011 at 03:19, Robert Haas wrote:
> 2011/1/21 KaiGai Kohei :
>> 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 similar things earlier, and it turned o
2011/1/21 KaiGai Kohei :
> 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 Company
--
Sent via pg
Robert Haas 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 procedure, the user
2011/1/22 Robert Haas :
> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
>> Robert Haas 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
On Fri, Jan 21, 2011 at 11:00 AM, Kohei KaiGai wrote:
> 2011/1/22 Robert Haas :
>> On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane wrote:
>>> Robert Haas writes:
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
> ALTER FUNCTION is supposed to cause plan invalidation in such a case.
> No
2011/1/22 Robert Haas :
> On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane 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
On Fri, Jan 21, 2011 at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane 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 ge
Robert Haas writes:
> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane 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 the
> database. Not sure how to ha
On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane wrote:
> Robert Haas 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 happ
Robert Haas 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 cause plan invalidat
2011/1/21 KaiGai Kohei :
> - 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 what happens with
Alvaro Herrera 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 subscription:
http://www.postgresql.
On Thu, Jan 20, 2011 at 9:59 AM, Alvaro Herrera
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 actually running pg
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.
(2011/01/20 13:01), Robert Haas wrote:
> 2011/1/19 KaiGai Kohei:
>>> 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,
2011/1/19 KaiGai Kohei :
>> 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 being
> control
(2011/01/20 12:10), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> 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 re
2011/1/5 KaiGai Kohei :
> 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 or less as-is. I'm
>> 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
2011/1/6 KaiGai Kohei :
> 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 feature being worthful,
>>> 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 descri
2011/1/6 KaiGai Kohei :
>> 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 when SELin
(2011/01/06 14:28), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> 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. :-)
>
Thanks f
2011/1/5 KaiGai Kohei :
> 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 this module, as oppose
(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 v
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. Sinc
(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 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 Lab
(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
63 matches
Mail list logo
