Sorry I see the comment. I'll continue the work to fulfill the comment.
2009/3/17 Heikki Linnakangas :
> Koichi Suzuki wrote:
>>
>> I believe all the issues pointed out in
>> http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
>> been covered in the current patch, as discussed
Koichi Suzuki wrote:
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the current patch, as discussed with Simon. I also
understand that we're running out of time.
I pointed out a few more issues here:
http://archive
Hi,
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the current patch, as discussed with Simon. I also
understand that we're running out of time.
I'd like to push this to pgFoundry first and then work again together
wi
Heikki Linnakangas writes:
> Improve Performance of Multi-Batch Hash Join for Skewed Data Sets
> I believe everyone's happy with the performance testing that's been
> done. Some of the logic ought to be moved to the planner, and maybe
> there's some other cleanup to do.
I'll take this up next.
Bruce Momjian wrote:
Well, we have been trying to go simplify the SE-PostgreSQL patch since
September, and while we have made progress, we still have work to do,
and at this point I think we have run out of time. I think we have
given it a fair shot, but I don't think it is going to make 8.4.
Bruce Momjian wrote:
Alvaro Herrera wrote:
Would it make sense to instead of removing and deferring pieces bit by bit to
instead work the other way around? Extract just the part of the patch that
maps SELinux capabilities to Postgres privileges as a first patch? Then
discuss any other parts indi
Alvaro Herrera wrote:
> > Would it make sense to instead of removing and deferring pieces bit by bit
> > to
> > instead work the other way around? Extract just the part of the patch that
> > maps SELinux capabilities to Postgres privileges as a first patch? Then
> > discuss any other parts individ
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas writes:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again fall
Heikki, I updated the SE-PostgreSQL patches:
http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1714.patch
http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1714.patch
http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1714.patch
http://sepgsql.googlecode.com/files/sep
KaiGai Kohei wrote:
I wonder why the vanilla PostgreSQL does not put pg_proc_aclcheck()
on the ExecCallTriggerFunc().
I don't think we can assume any trigger functions are "trusted",
because normal users with ACL_TRIGGER privilege can set their
procedures on the allowed tables.
It also means so
Robert Haas wrote:
* ACL_INSERT
The db_table:{insert} and db_column:{insert} for all the target
columns are checked. The table-level permission does not override
column-level permission, so the client need to have privileges
for both of objects. It is same as other permissions.
* ACL_SELECT
> * ACL_INSERT
> The db_table:{insert} and db_column:{insert} for all the target
> columns are checked. The table-level permission does not override
> column-level permission, so the client need to have privileges
> for both of objects. It is same as other permissions.
>
> * ACL_SELECT
> The d
Ron Mayer wrote:
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas writes:
KaiGai Kohei wrote:
* [..feature description..]
This again falls into the category of trying to have more fine-grained
permissions than vanilla PostgreSQL has
Would it make sense to instead of r
Alvaro Herrera writes:
> Gregory Stark escribió:
>> Would it make sense to instead of removing and deferring pieces bit by bit to
>> instead work the other way around? Extract just the part of the patch that
>> maps SELinux capabilities to Postgres privileges as a first patch? Then
>> discuss any
Alvaro Herrera wrote:
> Gregory Stark escribió:
>> Heikki Linnakangas writes:
>>
>>> KaiGai Kohei wrote:
* [..feature description..]
>>> This again falls into the category of trying to have more fine-grained
>>> permissions than vanilla PostgreSQL has
>> Would it make sense to instead of
Gregory Stark escribió:
> Heikki Linnakangas writes:
>
> > KaiGai Kohei wrote:
> >> * ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
> >>checks db_table:{update} permission on SELECT ... FOR SHARE OF,
> >>instead of db_table:{lock} permission.
> >
> > This again f
Heikki Linnakangas writes:
> KaiGai Kohei wrote:
>> * ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
>>checks db_table:{update} permission on SELECT ... FOR SHARE OF,
>>instead of db_table:{lock} permission.
>
> This again falls into the category of trying to have
KaiGai Kohei wrote:
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so
SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of tryin
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of trying to have more fine-gr
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of trying to have more fine-grained
permissions than van
Tom Lane wrote:
> Ron Mayer writes:
>> As far as I can tell, the community feels interested in the
>> feature set; but relatively unable to contribute since none
>> of the people have that much of a security background. It
>> seems the best way to fix that would be to get more people
>> with a se
Heikki, it is the list of updated patches:
http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1710.patch
http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1710.patch
http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1710.patch
http://sepgsql.googlecode.com/files/sepgs
Hannu Krosing wrote:
>> If we compile it with --enable-selinux, it has two working modes
>> controled by a guc option: sepostgresql (bool).
>> If it is disabled, all the sepgsql() invocations returns at
>> the head of themself without doing anything.
>>
>> I believe this behavior follows the pr
On Tue, 2009-03-10 at 11:44 -0700, Joshua D. Drake wrote:
> We would do the same thing with SE-Postgres.
No, no. I already experienced this with --integer-datetimes sets, and I
don't ever want to maintain another set. It is horrible.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org
Ron Mayer writes:
> As far as I can tell, the community feels interested in the
> feature set; but relatively unable to contribute since none
> of the people have that much of a security background. It
> seems the best way to fix that would be to get more people
> with a security background more
On Tue, 2009-03-10 at 14:59 -0400, Tom Lane wrote:
>
> > Which is exactly why we have two types of RPMS, --integer-datetimes
> and
> > not.
>
> Maybe Devrim is doing that, but nobody else is.
It is only available *if* yum repo conf file is specially configured and
if the distro is Fedora 10 an
On Tue, 2009-03-10 at 14:59 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Tue, 2009-03-10 at 14:14 -0400, Tom Lane wrote:
> >> You're just putting the hard decision onto packagers, who have no more
> >> knowledge than you do about what their users want, and (probably)
> >> considerably
"Joshua D. Drake" writes:
> On Tue, 2009-03-10 at 14:14 -0400, Tom Lane wrote:
>> You're just putting the hard decision onto packagers, who have no more
>> knowledge than you do about what their users want, and (probably)
>> considerably less understanding of the benefits/risks of some new
>> conf
On Tue, 2009-03-10 at 14:14 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Tue, 2009-03-10 at 14:47 -0300, Alvaro Herrera wrote:
> >> It was said upthread that SEPostgres is already packaged for Fedora.
>
> You're just putting the hard decision onto packagers, who have no more
> knowl
On Tue, 2009-03-10 at 10:49 -0700, Joshua D. Drake wrote:
> > It was said upthread that SEPostgres is already packaged for Fedora.
>
> Yes for but not by, AFAIK it is not actually included with Fedora.
It is, with the names "sepostgresql*".
> Essentially it is packaged like the PGSQLRPMS are pa
Tom Lane wrote:
> "Joshua D. Drake" writes:
>> I know we are a little uncomfortable here but KaiGai-San (forgive me if
>> I type that wrong) has proven to be a contributor in his own right,
>
> Not to put too fine a point on it, but: no, he hasn't. Show me one
> significant patch he's contribute
"Joshua D. Drake" writes:
> On Tue, 2009-03-10 at 14:47 -0300, Alvaro Herrera wrote:
>> It was said upthread that SEPostgres is already packaged for Fedora.
> Yes for but not by, AFAIK it is not actually included with Fedora.
"Included with Fedora" is an extremely loose concept. You can get it
On Tue, 2009-03-10 at 14:47 -0300, Alvaro Herrera wrote:
> Joshua D. Drake escribió:
>
> > Yes but I am also offering an opportunity for others to show up. Which
> > denying the patch does not do. If we provide SE support (even with
> > marking it experimental), I would wager that some Linux distr
Joshua D. Drake escribió:
> Yes but I am also offering an opportunity for others to show up. Which
> denying the patch does not do. If we provide SE support (even with
> marking it experimental), I would wager that some Linux distributions
> would begin to test it themselves which would allow us i
On Tue, 2009-03-10 at 13:08 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > I think you misunderstand me. I have watched this thread very closely
> > because it has specific strategic interest. For the record:
>
> > * This patch does scare me
> > * With great risk comes great reward
>
>
"Joshua D. Drake" writes:
> I think you misunderstand me. I have watched this thread very closely
> because it has specific strategic interest. For the record:
> * This patch does scare me
> * With great risk comes great reward
... or great failure. My key concern is that we are setting ourse
On Mon, 2009-03-09 at 20:55 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > I know we are a little uncomfortable here but KaiGai-San (forgive me if
> > I type that wrong) has proven to be a contributor in his own right,
>
> Perhaps it would help you calibrate the problem if I stated that
On Tue, Mar 10, 2009 at 08:02:05PM +0900, KaiGai Kohei wrote:
> Please wait for a while.
With all due respect to your hard work, waiting for this patch, even
one more hour, is exactly what we shouldn't do for 8.4. Sad as it is,
even if this patch were causing no controversy in its design, it woul
Heikki Linnakangas writes:
> If we drop the goal of trying to restrict what a superuser can do, is
> the patch still useful?
> One idea is to add a single "is superuser" permission to sepgsql.
The agreement back in January was that what we'd consider for 8.4 is
a patch that adds SELinux-driven
KaiGai Kohei writes:
> Heikki Linnakangas wrote:
>> If we drop the goal of trying to restrict what a superuser can do, is the
>> patch still useful?
>
> I want to keep permission checks on files specified by users, because
> the "superuser" permission affects very wide scope, and all or nothing
>
Heikki Linnakangas wrote:
This seems to be a recurring theme with this patch. We stripped
row-level permissions, now we have SET/SHOW and the "function
installation" permissions. And the read/write file permissions. To make
progress, we need to consider each new feature like that separately, as
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Heikki Linnakangas writes:
KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
The patch adds permission checks to SET/SHOW. If that's useful
functionality, it would be nice to see that as a separate
Hannu Krosing wrote:
> On Tue, 2009-03-10 at 09:56 +0900, KaiGai Kohei wrote:
>> Joshua D. Drake wrote:
> ...
>>> Is there any possibility of having it be enabled at compile time? The
>>> default would be know but those distributions that would like to make
>>> use of it could?
>> It was the design
On Tue, 2009-03-10 at 09:56 +0900, KaiGai Kohei wrote:
> Joshua D. Drake wrote:
...
> > Is there any possibility of having it be enabled at compile time? The
> > default would be know but those distributions that would like to make
> > use of it could?
>
> It was the design a half year ago, but Br
Heikki Linnakangas wrote:
+ void
+ sepgsqlCheckProcedureInstall(Relation rel, HeapTuple newtup,
HeapTuple oldtup)
+ {
[snip]
+ + case AccessMethodRelationId:
+ CHECK_PROC_INSTALL_PERM(pg_am, aminsert, newtup, oldtup);
+ CHECK_PROC_INSTALL_PERM(pg_am, ambeginscan, newtup,
Tom Lane wrote:
> Despite all that arm-waving, no one besides KaiGai-san has really
> stepped up to work on it. That leaves me not only with worries about
> the patch itself, but with an extremely low estimate of the community's
> interest in it. And it is too big, complicated, and risky to go in
Josh Berkus writes:
>> Frankly, what we have here is a large patch, with insanely difficult
>> correctness requirements, written by a Postgres newbie. If it doesn't
>> scare you, you haven't been paying attention. We have a long track
>> record of problems with patches written by people who thou
Tom,
Frankly, what we have here is a large patch, with insanely difficult
correctness requirements, written by a Postgres newbie. If it doesn't
scare you, you haven't been paying attention. We have a long track
record of problems with patches written by people who thought they were
ready to do
Jaime Casanova wrote:
On Mon, Mar 9, 2009 at 1:52 AM, KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
[3
On Mon, Mar 9, 2009 at 1:52 AM, KaiGai Kohei wrote:
> As I promised last week, SE-PostgreSQL patches are revised here:
>
> [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
> [3/5] http://sepgs
> Perhaps it would help you calibrate the problem if I stated that
> I wouldn't trust a patch for this purpose written by myself, let
> alone somebody who hasn't been hacking the backend for ten years.
> (Where "this purpose" means the type of control KaiGai-san seems
> to hope to enforce, as oppos
Joshua D. Drake wrote:
> On Mon, 2009-03-09 at 19:45 -0400, Tom Lane wrote:
>> Hannu Krosing writes:
>>> Can't it be kept separately maintained release for a version or two, so
>>> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
>>> easy way to compare both correctness and per
"Joshua D. Drake" writes:
> I know we are a little uncomfortable here but KaiGai-San (forgive me if
> I type that wrong) has proven to be a contributor in his own right,
Not to put too fine a point on it, but: no, he hasn't. Show me one
significant patch he's contributed before/beside this one.
On Mon, 2009-03-09 at 20:31 -0400, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > http://www.nsa.gov/applications/search/index.cfm?q=se-postgresql
> >
> > It is also part of the Secure OS project out of Japan (as far as I can
> > tell).
> >
> > I know we are a little uncomfortable here but Kai
Hannu Krosing wrote:
> Can't it be kept separately maintained release for a version or two, so
> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
> easy way to compare both correctness and performance ?
>
> Anyone remember how did Linux implement/introduce SE Linux ?
SELinux h
Joshua D. Drake wrote:
> http://www.nsa.gov/applications/search/index.cfm?q=se-postgresql
>
> It is also part of the Secure OS project out of Japan (as far as I can
> tell).
>
> I know we are a little uncomfortable here but KaiGai-San (forgive me if
> I type that wrong) has proven to be a contrib
On Mon, 2009-03-09 at 20:05 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Is there any possibility of having it be enabled at compile time?
>
> That's been assumed right along (unless you think it's okay for Postgres
> to stop working on every non-SELinux platform).
Good point.
> The
"Joshua D. Drake" writes:
> Is there any possibility of having it be enabled at compile time?
That's been assumed right along (unless you think it's okay for Postgres
to stop working on every non-SELinux platform). The problem here is
mostly about whether we have enough confidence in the code to
On Mon, 2009-03-09 at 19:45 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Can't it be kept separately maintained release for a version or two, so
> > that we will have both PostgreSQL and SE-PostgreSQL and thus have an
> > easy way to compare both correctness and performance ?
>
> Actually,
Hannu Krosing writes:
> Can't it be kept separately maintained release for a version or two, so
> that we will have both PostgreSQL and SE-PostgreSQL and thus have an
> easy way to compare both correctness and performance ?
Actually, KaiGai-san has been distributing a patched SEPostgres on
Fedora
On Mon, 2009-03-09 at 16:39 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Mar 9, 2009 at 4:04 PM, Tom Lane wrote:
> >> Now it's not really KaiGai-san's fault;
> >> the fundamental problem IMHO is that no one else is taking very much
> >> interest in the patch. But that in itself speaks
Robert Haas writes:
> On Mon, Mar 9, 2009 at 4:04 PM, Tom Lane wrote:
>> Now it's not really KaiGai-san's fault;
>> the fundamental problem IMHO is that no one else is taking very much
>> interest in the patch. But that in itself speaks volumes about whether
>> we actually want this patch or sho
On Mon, Mar 9, 2009 at 4:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane wrote:
>>> I've been convinced for awhile that the sepostgres project is going
>>> off the rails, and these last couple of exchanges just confirm the fear.
>
>> I'm not sure what you
Robert Haas writes:
> On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane wrote:
>> I've been convinced for awhile that the sepostgres project is going
>> off the rails, and these last couple of exchanges just confirm the fear.
> I'm not sure what you mean by "going off the rails". I think we are
> still
On Mon, Mar 9, 2009 at 1:25 PM, Tom Lane wrote:
> KaiGai Kohei writes:
>> Yes, the purpose of sepgsqlCheckProcedureInstall() is to prevent users
>> to invoke functions installed by other malicious/untrusted one, typically
>> known as trojan-horse.
>> ...
>> We should not assume only C-functions c
KaiGai Kohei writes:
> Yes, the purpose of sepgsqlCheckProcedureInstall() is to prevent users
> to invoke functions installed by other malicious/untrusted one, typically
> known as trojan-horse.
> ...
> We should not assume only C-functions can be installed on pg_conversion
> (and other internal s
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
I think I now understand what sepgsqlCheckProcedureInstall is trying to
achieve. It's trying to stop attacks where you trick another user to run
your malicious code. We had a seriou
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Heikki Linnakangas writes:
> > KaiGai Kohei wrote:
> >> As I promised last week, SE-PostgreSQL patches are revised here:
>
> > The patch adds permission checks to SET/SHOW. If that's useful
> > functionality, it would be nice to see that as a separate patc
Heikki Linnakangas writes:
> KaiGai Kohei wrote:
>> As I promised last week, SE-PostgreSQL patches are revised here:
> The patch adds permission checks to SET/SHOW. If that's useful
> functionality, it would be nice to see that as a separate patch, not
> requiring SE-Linux.
My goodness. This pa
KaiGai Kohei wrote:
> As I promised last week, SE-PostgreSQL patches are revised here:
The patch adds permission checks to SET/SHOW. If that's useful
functionality, it would be nice to see that as a separate patch, not
requiring SE-Linux.
I think it's leaking because current_setting(), set_config
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> As I promised last week, SE-PostgreSQL patches are revised here:
>
> There's checks for reading/writing files with COPY, in
> sepgsqlCheckFileRead sepgsqlCheckFileWrite). Doesn't the OS do similar
> checks when the process tries to invoke the read
KaiGai Kohei wrote:
As I promised last week, SE-PostgreSQL patches are revised here:
I think I now understand what sepgsqlCheckProcedureInstall is trying to
achieve. It's trying to stop attacks where you trick another user to run
your malicious code. We had a serious vulnerability of that kin
KaiGai Kohei wrote:
> As I promised last week, SE-PostgreSQL patches are revised here:
There's checks for reading/writing files with COPY, in
sepgsqlCheckFileRead sepgsqlCheckFileWrite). Doesn't the OS do similar
checks when the process tries to invoke the read()/write()? Is that not
enough?
--
As I promised last week, SE-PostgreSQL patches are revised here:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1704.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1704.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1704.patch
[4
KaiGai Kohei wrote:
One matter was "use" permission, but I can agree to integrate
it into "select" permission as the original design did.
Ok, great.
The other is view. When we use a view in the query, it is extracted
as a subquery and its query tree is fetched from pg_rewrite.ev_action
which
KaiGai Kohei wrote:
Heikki, Thanks for your comments.
Heikki Linnakangas wrote:
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
chang
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
The other one is it has two kind of reader permissions ("select" and
"use").
The "select" permission is applied when user tries to read tables/columns
and its contents are returned to the user.
The "use" permission is applied when user tries to read
KaiGai Kohei wrote:
The other one is it has two kind of reader permissions ("select" and
"use").
The "select" permission is applied when user tries to read tables/columns
and its contents are returned to the user.
The "use" permission is applied when user tries to read table/columns,
but its con
Heikki, Thanks for your comments.
Heikki Linnakangas wrote:
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
change you've already done
Ok, I've taken a quick look at this too. My first impression is that
this is actually not a very big patch. Much much smaller than I was
afraid of. It seems that dropping the row-level security and the other
change you've already done have helped a great deal.
My first question is, why does th
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1668.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1668.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1668.patch
[4/5] h
On Fri, Feb 27, 2009 at 5:06 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> executing: yum install libselinux gives "Package
>> libselinux-2.0.73-1.fc10.i386 already installed and latest version"
>
> Yeah, but have you got libselinux-devel? A general rule on Red Hat
> based systems is that comp
Jaime Casanova writes:
> executing: yum install libselinux gives "Package
> libselinux-2.0.73-1.fc10.i386 already installed and latest version"
Yeah, but have you got libselinux-devel? A general rule on Red Hat
based systems is that compiling a program that depends on library
package foo will re
On Sat, Feb 14, 2009 at 12:46 AM, KaiGai Kohei wrote:
> Jaime Casanova wrote:
>>
>> i only have ubuntu at hand, and i can install selinux from
>> repositories... do you see any problem with that?
>> i'm creating the VM now... will test on weekend...
>
> Now I checked the repository of Ubuntu, howe
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
Bruce Momjian wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
[3/5] http://sepgsql.googlecode.com/files/s
KaiGai Kohei wrote:
> The series of SE-PostgreSQL patches for v8.4 were updated:
> [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
> [3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.
On Thu, Feb 26, 2009 at 1:46 AM, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>>
>> Jaime Casanova wrote:
- List of updates:
* It is rebased to the latest CVS HEAD.
>>>
>>> actually i see fails when trying to apply
>>> sepgsql-core-8.4devel-r1627.patch to head (in pg_proc.h)...
>>> ""
KaiGai Kohei wrote:
Jaime Casanova wrote:
- List of updates:
* It is rebased to the latest CVS HEAD.
actually i see fails when trying to apply
sepgsql-core-8.4devel-r1627.patch to head (in pg_proc.h)...
"""
Hunk #4 FAILED at 113.
1 out of 4 hunks FAILED -- saving rejects to file
src/include/c
Jaime Casanova wrote:
On Wed, Feb 25, 2009 at 11:04 PM, KaiGai Kohei wrote:
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1627.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1627.patch
[3/5]
On Wed, Feb 25, 2009 at 11:04 PM, KaiGai Kohei wrote:
> The series of SE-PostgreSQL patches for v8.4 were updated:
>
> [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1627.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1627.patch
> [3/5]
> http://sepgsql
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1627.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1627.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1627.patch
[4/5] h
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.4devel-r1608.patch
[4/5] ht
The series of SE-PostgreSQL patches for v8.4 are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1590.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1590.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4d
On 2/14/09, Jaime Casanova wrote:
> On Sat, Feb 14, 2009 at 12:46 AM, KaiGai Kohei wrote:
>>
>
>> If you set up a VM from scratch, Fedora enables to install
>> via remote repository using minimum bootable image.
>>
>> http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/i386/iso/
On Sat, Feb 14, 2009 at 12:46 AM, KaiGai Kohei wrote:
>
> Now I checked the repository of Ubuntu, however, I can find
> several matters to build/run SE-PostgreSQL.
> - The default security policy is quite old.
> Is does not contain SE-PostgreSQL support which is merged
> at the refpolicy-2008070
KaiGai Kohei wrote:
If you set up a VM from scratch, Fedora enables to install
via remote repository using minimum bootable image.
http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/i386/iso/
I don't think it is not a essential for you to resolve troubles
related to SELi
Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 8:32 PM, KaiGai Kohei wrote:
If you can help to test the patches, I recommend you to install Fedora 10
on your VM images, because it includes SELinux in the default and its
default security policy (selinux-policy-targeted) also supports
SE-PostgreSQ
On Fri, Feb 13, 2009 at 8:32 PM, KaiGai Kohei wrote:
>>
> If you can help to test the patches, I recommend you to install Fedora 10
> on your VM images, because it includes SELinux in the default and its
> default security policy (selinux-policy-targeted) also supports
> SE-PostgreSQL.
>
i only h
Jaime Casanova wrote:
On Fri, Feb 13, 2009 at 9:07 AM, Joshua Brindle wrote:
KaiGai Kohei wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
[2/5]
http://sepgsql.googlecode.com/files
1 - 100 of 427 matches
Mail list logo
