Thanks for the pointer. Here is a diff to fix the problem. How does it
look to you?
> This code in psql/command.c allows *any* system user to place a
> predictably named symbolic link in /tmp and use it to alter/destroy
> files owned by the user running psql. (tested - postgresql 7.0.2).
>
> A
> Someone ought to backpatch to REL_7_0_PATCHES, as it's syslog also
> looks bad...
Not sure if we will have a 7.0.4, and I can't see it as a major bug
problem anyway.
>
> LER
>
> * Bruce Momjian <[EMAIL PROTECTED]> [001124 22:38]:
> > Applied. :-)
> >
> > > * Larry Rosenman <[EMAIL PROTECT
Someone ought to backpatch to REL_7_0_PATCHES, as it's syslog also
looks bad...
LER
* Bruce Momjian <[EMAIL PROTECTED]> [001124 22:38]:
> Applied. :-)
>
> > * Larry Rosenman <[EMAIL PROTECTED]> [001123 01:10]:
> > > * Tom Lane <[EMAIL PROTECTED]> [001122 22:44]:
> > > Makes sense. Here's a ne
This code in psql/command.c allows *any* system user to place a
predictably named symbolic link in /tmp and use it to alter/destroy
files owned by the user running psql. (tested - postgresql 7.0.2).
All the information a potential attacker would need are available via a
simple 'ps'.
It might (un
Andrew Bartlett wrote:
>
> This code in psql/command.c allows *any* system user to place a
> predictably named symbolic link in /tmp and use it to alter/destroy
> files owned by the user running psql. (tested - postgresql 7.0.2).
>
> All the information a potential attacker would need are availa
I'm building a new geo type and would like to index it. I have heard about
RTREE and boundary box but I'm clueless for the moment about the
implementation
I have tried to look into PG source code to find the location where the
indexing is done of current line object is done, but couldn't pin
Applied. :-)
> * Larry Rosenman <[EMAIL PROTECTED]> [001123 01:10]:
> > * Tom Lane <[EMAIL PROTECTED]> [001122 22:44]:
> > Makes sense. Here's a new patch, now the output even looks better:
> > Nov 23 00:58:04 lerami pg-test[9914]: [2-1] NOTICE: QUERY PLAN:
> > Nov 23 00:58:04 lerami pg-test[9
Applied.
> * Tom Lane <[EMAIL PROTECTED]> [001122 22:44]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > Looking some more, I found some other places that need a space (I
> > > suspect...), so here is an updated patch.
> >
> > This seems like the wrong way to go about it, because anytime
> Bruce Momjian writes:
>
> > The 7.1 code will the socket location configurable.
>
> Btw., are you still about to change it to the directory rather than the
> file? I'd suggest that you change the GUC parameter to
> "unix_socket_directory", to be consistent in naming with related
> parameters.
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> I think your complaints about RedHat's default are right back in your
> lap ;-). Do you want to ignore their default, or not?
Yes, I want to ignore their default. This problem is more than just
cosmetic, thanks to the bugs that sparked
Lamar Owen <[EMAIL PROTECTED]> writes:
> A command-line argument to initdb would suffice to override -- maybe a
> '--initlocale' parameter??
Hardly need one, when setting LANG or LC_ALL will do just as well.
> Now, what sort of default for --initlocale.
I think your complaints about RedHat'
Tom Lane wrote:
> Don Baccus <[EMAIL PROTECTED]> writes:
> > Are you SURE you want to use en_US collation? [no]
> > (ask the question, default to no?)
> > Yes, a question in initdb is ugly, this whole thing is ugly.
> A question in initdb won't fly for RPM installations, since the RPMs
> try t
Don Baccus <[EMAIL PROTECTED]> writes:
> Are you SURE you want to use en_US collation? [no]
> (ask the question, default to no?)
> Yes, a question in initdb is ugly, this whole thing is ugly.
A question in initdb won't fly for RPM installations, since the RPMs
try to do initdb themselves (or am
At 07:32 PM 11/24/00 -0500, Tom Lane wrote:
>Possible compromise: let initdb accept en_US, but have it spit out a
>warning message:
>
>NOTICE: initializing database with en_US collation order.
>If you're not certain that's what you want, then it's probably not what
>you want. We recommend you set
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Collation was the same, regardless of the --enable-locale
> > setting. I got lots of 'bug' reports about the RPM's failing
> Hmm. I reviewed that thread and found this comment from you:
> : In a nutshell, yes. /etc/sysconfig/i18n
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Possible compromise: let initdb accept en_US, but have it spit out a
>> warning message:
> I certainly don't like treating en_US specially, when in fact all locales
> are affected by this.
Well, my thought was that another locale
Tom Lane writes:
> Possible compromise: let initdb accept en_US, but have it spit out a
> warning message:
>
> NOTICE: initializing database with en_US collation order.
> If you're not certain that's what you want, then it's probably not what
> you want. We recommend you set LC_COLLATE to "C" a
Lamar Owen <[EMAIL PROTECTED]> writes:
> Collation was the same, regardless of the --enable-locale
> setting. I got lots of 'bug' reports about the RPM's failing
> regression, giving an unexpected sort order (see the archives -- the
> best model thread's start post is:
> http://www.postgresql.org
Vadim,
In xlog.c, the declaration of struct ControlFileData says:
/*
* MORE DATA FOLLOWS AT THE END OF THIS STRUCTURE - locations of data
* dirs
*/
Is this comment accurate? I don't see any sign in the code of placing
extra data after the declared structure. If you're plann
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Oh, and to make matters that much worse, on a RedHat system it doesn't
> > matter if you build with or without --enable-locale -- locale support is
> > in the libc used, and locale support gets used regardless of what you
> > select on t
Possible compromise: let initdb accept en_US, but have it spit out a
warning message:
NOTICE: initializing database with en_US collation order.
If you're not certain that's what you want, then it's probably not what
you want. We recommend you set LC_COLLATE to "C" and re-initdb.
For more informa
Lamar Owen <[EMAIL PROTECTED]> writes:
> I am not at all happy about the 'broken' RedHat locale -- the quick and
> dirty solution is to remove or rename '/etc/sysconfig/i18n' -- but that
> doesn't cure the root issue.
Actually, that suggestion points out that just nailing down LC_COLLATE
at initd
Lamar Owen <[EMAIL PROTECTED]> writes:
> Oh, and to make matters that much worse, on a RedHat system it doesn't
> matter if you build with or without --enable-locale -- locale support is
> in the libc used, and locale support gets used regardless of what you
> select on the configure line :-(.
I
Tom Lane wrote:
> that contains only (or mostly) words like that. But I've got strong
> doubts that the average user of a default RedHat installation expects
> *all* data to get sorted that way, or that he wants us to honor a
> default that he didn't ask for to the extent of disabling LIKE
> opti
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> I have now received positive proof that en_US sort order on RedHat is
>> broken. For example, it asserts
>> '/root/' < '/root0'
>> but
>> '/root/t' > '/root0'
>> I defy you to find anyone in the US who will say that that is a
>> reasonable definitio
Tom Lane writes:
> >> Also, since "LC_COLLATE=en_US" seems to misbehave rather spectacularly
> >> on recent RedHat releases, I propose that initdb change "en_US" to "C"
> >> if it finds that setting. (Are there any platforms where there are
> >> non-bogus differences between the two?)
>
> > The
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I propose, therefore, that in an --enable-locale installation, initdb
>> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
>> backend startup should restore these settings from pg_control.
> Note that when thes
Tom Lane writes:
> I propose, therefore, that in an --enable-locale installation, initdb
> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
> backend startup should restore these settings from pg_control.
Note that when these are unset there might still be a "catch-all" loca
... and I am not going to allow 7.1 to go out without a fix for this
class of problems. I'm fed up ;-)
As near as I can tell from the setlocale() man page, the only locale
categories that are really hazardous for us are LC_COLLATE and LC_CTYPE;
the other categories like LC_MONETARY affect only I
> > - Original Message -
> > From: "Dan Wilson" <[EMAIL PROTECTED]>
> > To: "pgsql general" <[EMAIL PROTECTED]>
> > Sent: Sunday, November 19, 2000 9:33 AM
> > Subject: DB and Table Permissions
> >
> > > Is there a reason why _any_ user can create a table on a database?
Even if
> > > they
<[EMAIL PROTECTED]> writes:
> Strnage isn't it
No. That's the intended and documented behavior. See the manual, eg,
http://www.postgresql.org/users-lounge/docs/7.0/postgres/syntax525.htm
regards, tom lane
Max Fonin <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
I guess the problem is that PL/pgSQL doesn't handle opaque type correctly.
>>
>> No it doesn't, which is not surprising considering that opaque isn't
>> really a type at all. The error message could be improved thou
Hi,
I had a problem porting applications from mySQL.
I can't find info on this in the docs... so mailed the list, sorry for
my english.
I create the fileds name with first letter uppercase, I need this way,
because the result set must have the fileds name with the correct case
in PHP.
I woul
On Thu, 23 Nov 2000 11:13:28 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Max Fonin <[EMAIL PROTECTED]> writes:
> > I guess the problem is that PL/pgSQL doesn't handle opaque type correctly.
>
> No it doesn't, which is not surprising considering that opaque isn't
> really a type at all. The erro
Hi,
First excuse me for my bad english,
I use postgresql V7.0.2 with linux and I found a stange
result with create table.
CREATE TABLE "UTILISATEURS" (
..
);
Ok no problem, and when i use \\dt under pgsql i see this
name. But when i write select * from UTILISATEURS ,it doesn't
work. i
Carlos Jacobs wrote:
>
> Hi:
> I have a MS Access database with tables containing TEXT fields.
> I need import that info in a postgres 7 table.
> How to do it?
> If I use copy from, dont work.
I have a perl program which will import this sort of multi-line CSV data
that is not handled by the COP
At 07:49 24/11/00 -, Peter Mount wrote:
>There's bound to be a better way, but in the NT resource kit there was a
>tool you can use to make any .exe a service.
Without modifying the postmaster, this is probably the best solution. An NT
service has to handle and respond to various events (STAR
37 matches
Mail list logo
