Re: [HACKERS] postgres vulnerability

Neil Conway <[EMAIL PROTECTED]> writes: > Gaetano Mendola wrote: >> Here http://www.sans.org/top20/#u9 >> are listed postgres vulnerability it's sad see that almost all >> are related to third part components > "Almost all"? By my count, 12 of the 17 vulnerabilities refer to > legitimate problem

Re: [HACKERS] postgres vulnerability

Gaetano Mendola wrote: Here http://www.sans.org/top20/#u9 are listed postgres vulnerability it's sad see that almost all are related to third part components "Almost all"? By my count, 12 of the 17 vulnerabilities refer to legitimate problems in PostgreSQL, its RPM distribution, or the ODBC drive

Re: [HACKERS] Notes on config-file-locations patch

Peter Eisentraut wrote: > Tom Lane wrote: > > The main difference between this and the CVS-tip behavior is that > > if you want to specify the main config file directly, you write > > --config_file instead of -D. I think that's less confusing than > > overloading -D with multiple meanings. > > I

Re: [HACKERS] [BUGS] BUG #1270: stack overflow in thread in fe_getauthname

Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, we got a report. I just thinkg 8192 is excessive for that > structure, and if someone is having a problem, others might as well. >> On Tru64 UNIX, sysconf(_SC_GETPW_R_SIZE_MAX) returns 1024. I'd be more impressed by this line of reasoning if _SC_GE

Re: [HACKERS] Security implications of config-file-location patch

Bruce Momjian <[EMAIL PROTECTED]> writes: > I was going to suggest 'data_dir' but I see 'directory' is fully spelled > out in all other GUC variables in postgresql.conf, so let's use > 'data_directory'. Done. regards, tom lane ---(end of broadcast)

Re: [HACKERS] [BUGS] BUG #1270: stack overflow in thread in fe_getauthname

OK, we got a report. I just thinkg 8192 is excessive for that structure, and if someone is having a problem, others might as well. --- Peter Davie wrote: > Hi Guys, > > Please refer to >

Re: [HACKERS] Security implications of config-file-location patch

Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> As of CVS tip, if you are using the config-file-location-changing > >> features, anybody can find out the data directory location via > >> "show pgdata"; > > > Btw., couldn't we come up with a more descriptive

Re: [HACKERS] postgres vulnerability

Stephan Szabo wrote: On Sat, 9 Oct 2004, Stephan Szabo wrote: On Sat, 9 Oct 2004, Gaetano Mendola wrote: Here http://www.sans.org/top20/#u9 are listed postgres vulnerability it's sad see that almost all are related to third part components I'd go further than sad and say irresponsible for the on

Re: [HACKERS] postgres vulnerability

On Sat, 9 Oct 2004, Stephan Szabo wrote: > > On Sat, 9 Oct 2004, Gaetano Mendola wrote: > > > Here http://www.sans.org/top20/#u9 > > are listed postgres vulnerability it's sad see that almost all > > are related to third part components > > I'd go further than sad and say irresponsible for the o

Re: [HACKERS] postgres vulnerability

On Sat, 9 Oct 2004, Gaetano Mendola wrote: > Here http://www.sans.org/top20/#u9 > are listed postgres vulnerability it's sad see that almost all > are related to third part components I'd go further than sad and say irresponsible for the ones that are like that. ---(end

[HACKERS] postgres vulnerability

Here http://www.sans.org/top20/#u9 are listed postgres vulnerability it's sad see that almost all are related to third part components Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://

Re: [HACKERS] SQL-Invoked Procedures for 8.1

Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > As previously mentioned, AS is already used by the SQL standard for > > a different purpose in this context. > > Hm? [ reads spec ... ] Oh, you mean . > Does that actually do anything useful? It looks like it's just > a random sh

Re: [HACKERS] SSL with Beta3 - "could not load root certificate file"

The SSL certificate (server.crt) was made following the instructions in the Postgres documentation. Note, that root.crt is not specified in this documentation. Yes it is; see http://developer.postgresql.org/docs/postgres/ssl-tcp.html near the bottom of the page, and also http://developer.postgresq

Re: [HACKERS] SQL-Invoked Procedures for 8.1

Peter Eisentraut <[EMAIL PROTECTED]> writes: > As previously mentioned, AS is already used by the SQL standard for a > different purpose in this context. Hm? [ reads spec ... ] Oh, you mean . Does that actually do anything useful? It looks like it's just a random shortcut for a CAST expression

Re: [HACKERS] Notes on config-file-locations patch

Tom Lane wrote: > The main difference between this and the CVS-tip behavior is that > if you want to specify the main config file directly, you write > --config_file instead of -D. I think that's less confusing than > overloading -D with multiple meanings. I seem to recall that this was proposed

Re: [HACKERS] Security implications of config-file-location patch

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> As of CVS tip, if you are using the config-file-location-changing >> features, anybody can find out the data directory location via >> "show pgdata"; > Btw., couldn't we come up with a more descriptive parameter name than > "pgdata

Re: [HACKERS] SQL-Invoked Procedures for 8.1

Tom Lane wrote: > The main thing that I'm not happy about is the syntax. I'm going to > resist commandeering => for this purpose, and I don't see any way to > use that symbol for this without forbidding it as a user-defined > operator. I previously suggested using AS, which is already a fully > re

Re: [HACKERS] Security implications of config-file-location patch

Tom Lane wrote: > As of CVS tip, if you are using the config-file-location-changing > features, anybody can find out the data directory location via > "show pgdata"; Btw., couldn't we come up with a more descriptive parameter name than "pgdata"? -- Peter Eisentraut http://developer.postgresql.o

[HACKERS] Notes on config-file-locations patch

There are some loose ends and inconsistencies left in the config-file- locations feature, which I'm planning to clean up. One problem is that although the GUC variables allow you to find out the location of the secondary config files, you can't verify which main config file (postgresql.conf) the p

Re: [HACKERS] beta3 on unixware 714

On Sat, 9 Oct 2004, Tom Lane wrote: > Date: Sat, 09 Oct 2004 11:46:36 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] beta3 on unixware 714 > > [EMAIL PROTECTED] writes: > > not sure: > > createlang: language

Re: [HACKERS] beta3 on unixware 714

[EMAIL PROTECTED] writes: > not sure: > createlang: language installation failed: ERROR: could not load library > > "/home/postgres/postgresql-snapshot/src/test/regress/./tmp_check/install//usr/local/pgsql/lib/plpgsql.so": > dynamic linker: > /home/postgres/postgresql-snapshot/src/test/regress

Re: [HACKERS] beta3 on unixware 714

On Sat, 9 Oct 2004, Tom Lane wrote: > Date: Sat, 09 Oct 2004 11:19:51 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: pgsql-hackers list <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] beta3 on unixware 714 > > [EMAIL PROTECTED] writes: > > Also, I tried to compile with --ena

Re: [HACKERS] beta3 on unixware 714

[EMAIL PROTECTED] writes: > Also, I tried to compile with --enable-cassert, this causes a "symbol not > found" in createlang while make check. Sounds like picking up the wrong version of a shared library. regards, tom lane ---(end of broadcast)

Re: [HACKERS] SSL with Beta3 - "could not load root certificate file"

"G Reina" <[EMAIL PROTECTED]> writes: > The error in the serverlog is: > LOG: could not load root certificate file > "/database/local/pgsql/data/root.crt": No such file or directory > DETAIL: Will not verify client certificates. This is not an error. > The SSL certificate (server.crt) was made

[HACKERS] beta3 on unixware 714

Hi all, I've been giving a shot to beta3 since yesterday. make check produces a hang when testing the 14 parallel tests (limit...) at that point, no tests ever returns, one postmaster is 100% cpu bound and nothing occurs. Beta2 was ok; I wonder what changed. Also, I tried to compile with --enable

Re: [HACKERS] compact PostgreSQL

Yui, Perhaps what you need is not a compacted source (which still needs additional space to compile) but instead a binary distribution. Depending on the OS you're using, you might be able to find pre-compiled binaries which would take much less space. HTH S On Sat, 09 Oct 2004 22:03:48 +0900,

[HACKERS] compact PostgreSQL

Hi! (BI would like to install PostgreSQL. But my pc does not have much space. (BSo I would like to make compact PostgreSQL. Does anyone know how to make (Bcompact PostgreSQL? For example, to make comment out source code and (Bcompile. (B (B (BRegards, (BYui (B (B (B--

Re: [HACKERS] more dirmod CYGWIN

Tom Lane schrieb: Bruce Momjian <[EMAIL PROTECTED]> writes: Reini Urban wrote: Now that postgres 8.0 is win32 native is it still necessary support the cygwin ? FYI: If you drop it I will still provide cygwin packages. I just need it for testing and writing applications targetted to unix. With win

[HACKERS] SSL with Beta3 - "could not load root certificate file"

I know that some SSL stuff was corrected between beta2 and beta3. I've been getting an error at postmaster startup, but don't know enough about SSL to determine if it is ok. Encryption seems to be working (which is all I care about). The error in the serverlog is: LOG: could not load root cert