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
Andrew Dunstan writes:
> Tom Lane wrote:
>> How early is early? The proposed call sites for init_dump_utils seem
>> already long past the point where any libc-level infrastructure would
>> think it is "initialization" time.
> Well, I think at least it needs to be done where other threads won't
ITAGAKI Takahiro writes:
> For resource-based profilers, we have DTrace probes[1] and continue to
> extend them[2], but unfortunately DTrace only works on Solaris and limited
> platforms.
FWIW, the systemtap guys are really, really close to having a working
DTrace equivalent for Linux:
http://gnu
Em Ter, 2009-03-10 às 10:23 +0900, ITAGAKI Takahiro escreveu:
> Thanks for testing. Network (or communication between pgbench and postgres)
> seems to be a bottleneck on your machine.
Yes, it is a very poor machine for quicktest. I'll test other
environments tomorrow.
> > Two questions here:
> >
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Actually, why bother with init_dump_utils at all?
Well, the Windows reference I have suggests TlsAlloc() needs to be
called early in the initialisation process ...
How early is early? The proposed call sites
> 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
"Dickson S. Guedes" wrote:
> Compiled and Works fine here on Ubuntu 8.04 2.6.25.15-bd-mod #1 SMP
> PREEMPT Thu Nov 27 10:05:44 BRST 2008 i686 GNU/Linux
Thanks for testing. Network (or communication between pgbench and postgres)
seems to be a bottleneck on your machine.
> Two questions here:
>
Andrew Dunstan writes:
> Tom Lane wrote:
>> Actually, why bother with init_dump_utils at all?
> Well, the Windows reference I have suggests TlsAlloc() needs to be
> called early in the initialisation process ...
How early is early? The proposed call sites for init_dump_utils seem
already long
Pg_lesslog, a PgFoundry project to reduce a size of archive log, has
released new pg_lesslog 1.2. This fixes a bug of incorrect handling
of XLOG_BTREE_SPLIT_R WAL record.
Project home is here: http://pglesslog.projects.postgresql.org/
Download page is here: http://pgfoundry.org/frs/?group_id=10
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
Tom Lane wrote:
It makes me a bit
nervous because there are some other programs that are linking
dumputils.c (psql and some in src/bin/scripts/) and even calling fmtId.
Actually, why bother with init_dump_utils at all? fmtId could be made
to initialize the ID variable for itself on firs
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
Patch applied. Thanks.
---
Robert Lor wrote:
> Attached is the doc patch for the recently added probes.
>
> -Robert
>
> Index: doc/src/sgml/monitoring.sgml
> =
"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,
Alvaro Herrera writes:
> Hmm, if pg_restore is the only program that's threaded, why are you
> calling init_dump_utils on pg_dump and pg_dumpall?
... because fmtId will crash on *any* use without that.
> It makes me a bit
> nervous because there are some other programs that are linking
> dumputi
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
Andrew Dunstan writes:
> + void
> + init_dump_utils()
This should be
> + void
> + init_dump_utils(void)
please. We don't do K&R C around here. I'd lose the added retval
variable too; that's not contributing anything.
> ! #endif;
Semicolon is bogus here.
Looks pretty sane otherwise.
Andrew Dunstan wrote:
>
> The attached patch fixes two issues with parallel restore:
>
>* the static buffer problem in dumputils.c::fmtId() on Windows
> (solution: use thread-local storage)
>* ReopenPtr() is called too often
Hmm, if pg_restore is the only program that's threaded, why
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
The attached patch fixes two issues with parallel restore:
* the static buffer problem in dumputils.c::fmtId() on Windows
(solution: use thread-local storage)
* ReopenPtr() is called too often
There is one remaining bug I know of that I can reproduce: we can get
into deadlock when
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, 2009-03-09 at 15:48 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Magnus Hagander wrote:
> >> but maybe it's better to use -i and -I, and thus change them both?
>
> > That's already used:
>
> > -i, --ignore-version proceed even when server version mismatches
> >
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
Greg Sabino Mullane wrote:
>>> -i, --ignore-version proceed even when server version mismatches
>>>pg_dump version
>> Proposal: drop the short forms of these two switches entirely.
>> Anybody who actually needs the capability can write "--inserts".
>
> I thought a
>> -i, --ignore-version proceed even when server version mismatches
>>pg_dump version
>
> Proposal: drop the short forms of these two switches entirely.
> Anybody who actually needs the capability can write "--inserts".
I thought about something like that, but th
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>
>>> Magnus Hagander wrote:
but maybe it's better to use -i and -I, and thus change them both?
>>
>>
>>> That's already used:
>>>
>>
>>
>>> -i, --ignore-version proceed even when
Tom Lane wrote:
"Kevin Grittner" writes:
Magnus Hagander wrote:
but maybe it's better to use -i and -I, and thus change them both?
That's already used:
-i, --ignore-version proceed even when server version mismatches
pg_dump v
"Kevin Grittner" writes:
> Magnus Hagander wrote:
>> but maybe it's better to use -i and -I, and thus change them both?
> That's already used:
> -i, --ignore-version proceed even when server version mismatches
>pg_dump version
Proposal: drop the short forms
>>> Magnus Hagander wrote:
> Kevin Grittner wrote:
>> Are you proposing to leave -D as is?
>
> I was :-)
>
> but maybe it's better to use -i and -I, and thus change them both?
That's already used:
-i, --ignore-version proceed even when server version mismatches
Kevin Grittner wrote:
Magnus Hagander wrote:
>> +1 with breaking it, but with a better message (and let's call it
>> breaking, not deprecating).
>
> Are you proposing to leave -D as is?
I was :-)
but maybe it's better to use -i and -I, and thus change them both?
//Magnus
--
Sent via p
>>> Magnus Hagander wrote:
> +1 with breaking it, but with a better message (and let's call it
> breaking, not deprecating).
Are you proposing to leave -D as is?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Selena Deckelmann wrote:
> Tom Lane wrote:
>> Greg Sabino Mullane writes:
>>> ...
>>> deprecate -d by having it throw an exception when used.
>>
>> "Deprecate" does not mean "break".
> ...
> While this change may break existing scripts...less painful
Why do people want a failure rather than warni
Tom Lane wrote:
> "Joshua D. Drake" writes:
>> Sorry Tom. Greg is correct here although I disagree with his wording. It
>> should be removed and if someone passes -d it should throw an ERROR that
>> says something like:
>> ERROR: -d has been replaced by -I
>
> Well, if you want to break it, we ca
Tom Lane wrote:
Greg Sabino Mullane writes:
The solution I came up with is to use a new letter, -I, and to deprecate -d by
having it throw an exception when used.
"Deprecate" does not mean "break".
This '-d' thing is more than just a matter of reading the documentation.
Our other command l
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
If this is the worst inconsistency you can find in our system tables
after +20 years of development, I feel pretty good.
---
Joshua D. Drake wrote:
> Hello,
>
> Something that continues to grind my teeth about our software
"Joshua D. Drake" writes:
> Sorry Tom. Greg is correct here although I disagree with his wording. It
> should be removed and if someone passes -d it should throw an ERROR that
> says something like:
> ERROR: -d has been replaced by -I
Well, if you want to break it, we can debate about the wisdom
On Mon, 2009-03-09 at 13:30 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Sorry Tom. Greg is correct here although I disagree with his wording. It
> > should be removed and if someone passes -d it should throw an ERROR that
> > says something like:
> > ERROR: -d has been replaced by -I
>
On Mon, 2009-03-09 at 13:59 -0400, Bruce Momjian wrote:
> If this is the worst inconsistency you can find in our system tables
> after +20 years of development, I feel pretty good.
I was using a single example. This would be a large project I am sure
and of course we should feel good. In all I wou
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
On Mon, 2009-03-09 at 12:48 -0400, Tom Lane wrote:
> Greg Sabino Mullane writes:
> > The solution I came up with is to use a new letter, -I, and to deprecate -d
> > by
> > having it throw an exception when used.
>
> "Deprecate" does not mean "break".
Sorry Tom. Greg is correct here although I d
Greg Sabino Mullane writes:
> The solution I came up with is to use a new letter, -I, and to deprecate -d by
> having it throw an exception when used.
"Deprecate" does not mean "break".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Attached is a patch to fix the annoying footgun that is pg_dump -d. Myself and
many others I know have all at one time or another done this:
psql -h localhost -U greg -d postgres
pg_dump -h localhost -U greg -d postgres > dumpfile
The latter command silently succeeds, but only through the combin
Magnus Hagander wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I have found the source of the problem I saw. dumputils.c:fmtId()
uses a static PQExpBuffer which it initialises the first time it's
called. This gets clobbered by simultaneous calls
Zdenek Kotala wrote:
I attached fix which modify foreign_data test. It fix problem with Czech
collation when numbers are ordered after letters. I retyped affected
column to name datatype which uses bitwise cmp.
I have chosen a different fix: rename the identifiers so the ordering
problem doesn
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
ITAGAKI Takahiro wrote:
Peter Eisentraut wrote:
ITAGAKI Takahiro wrote:
Here is a patch to allow 'on' and 'off' as input texts for boolean.
Regarding your FIXME comment, I think parse_bool* should be in bool.c
and declared in builtins.h, which guc.c already includes.
(Conceptually, the vali
2009/3/9 Alvaro Herrera :
> Tom Lane wrote:
>> Alvaro Herrera writes:
>> > A guy just reported on pgsql-es-ayuda that he's getting
>> > ERROR: item pointer (543108,2) already exists
>> Test case?
>
> Apparently there's a crash involved ...
>
I asked to Gabriel. The exactly version is 8.3.6.
He ju
Em Seg, 2009-03-09 às 13:55 +0900, ITAGAKI Takahiro escreveu:
> Therefore, I'd like to propose an profiler with sampling approach in 8.5.
> The attached patch is an experimental model of the profiler.
> Each backends reports its condtion in PgBackendStatus.st_condition
> and the stats collector pro
* 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
On Mar 9, 2009, at 4:53 AM, Dave Page wrote:
On Sun, Mar 8, 2009 at 5:03 AM, Robert Haas
wrote:
The original patch was submitted by Koichi Suzuki - quite a few other
people have looked at it and provided comments. Simon Riggs was
assigned as the original reviewer, but for some reason Dave
Fujii Masao wrote:
On Tue, Mar 3, 2009 at 1:47 PM, Fujii Masao wrote:
Hi Suzuki-san,
On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki wrote:
My reply to Gregory's comment didn't have any objections. I believe,
as I posted to Wiki page, latest posted patch is okay and waiting for
review.
One
I have applied the following comment to summarize the visibility rules.
I also added a URL about the Halloween problem.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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
Tom Lane wrote:
> Alvaro Herrera writes:
> > A guy just reported on pgsql-es-ayuda that he's getting
> > ERROR: item pointer (543108,2) already exists
> >
> Test case?
Apparently there's a crash involved ...
--
Alvaro Herrera
Alvaro Herrera writes:
> A guy just reported on pgsql-es-ayuda that he's getting
> ERROR: item pointer (543108,2) already exists
>
Test case?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
David Lee Lambert wrote:
On 6 mar, 22:44, and...@dunslane.net (Andrew Dunstan) wrote:
Holger Hoffstaette wrote:
On Fri, 06 Mar 2009 14:32:25 -0600, Kenneth Marshall wrote:
On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote:
Yes, I discovered this a few we
Hi,
A guy just reported on pgsql-es-ayuda that he's getting
ERROR: item pointer (543108,2) already exists
Apparently this message only occurs on GIN, in insertItemPointer
Reading that routine I cannot help but wonder -- where is
g
Andrew Dunstan wrote:
>
>
> Alvaro Herrera wrote:
>> Andrew Dunstan wrote:
>>
>>
>>> I have found the source of the problem I saw. dumputils.c:fmtId()
>>> uses a static PQExpBuffer which it initialises the first time it's
>>> called. This gets clobbered by simultaneous calls by Windows thread
Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> Worst case, we could say that parallel restore isn't supported on
>> mingw. I'm not entirely sure why we bother with that platform at all...
>
> I think you're confusing it with cygwin ...
Yeah. Much as I hate working around the quirks of mingw, I de
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
On 6 mar, 22:44, and...@dunslane.net (Andrew Dunstan) wrote:
> Holger Hoffstaette wrote:
> > On Fri, 06 Mar 2009 14:32:25 -0600, Kenneth Marshall wrote:
> >> On Fri, Mar 06, 2009 at 02:58:30PM -0500, Andrew Dunstan wrote:
> >>> Yes, I discovered this a few weeks ago. [...]
>
> Maybe someone can tra
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?
--
On Sun, Mar 8, 2009 at 5:03 AM, Robert Haas wrote:
>
> The original patch was submitted by Koichi Suzuki - quite a few other
> people have looked at it and provided comments. Simon Riggs was
> assigned as the original reviewer, but for some reason Dave Page
> removed his name from the wiki a few
2009/3/9 Ryan Bradetich :
> On Sun, Mar 8, 2009 at 4:36 PM, Tom Lane wrote:
>> Ryan Bradetich writes:
>>> This is one of the things I wanted to start looking at for 8.5.
>>> My idea was to optionally use : or @ (not sure which is more popular) to
>>> specify this token is only a variable.
>>
>> T
78 matches
Mail list logo
