[BUGS] instruction
Dear Mr or miss : please give a instruction of PostgreSQL 8.1.0 that be installed on the gentoo linux OS,thank you very much! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities
The following bug has been logged online: Bug reference: 2052 Logged by: Ferindo Middleton Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Windows 2000 Description:Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities Details: This bug report involves more than one proposed bug. I work at a federal government agency. The information technology division at this agency refuses to allow the database version 8.0.4 on their network because of several security vulnerabilities they noticed when testing the software application. The database would run on a Windows 2000 Professional computer system. The division I work for wants to use the database as a backend to a set Java Server Pages I developed to be served via Apache Tomcat. My application works great with PostgreSQL but the problem is getting the IS team at this agency to accept PostgreSQL db. I know nothing about hacking PostgreSQL. I am merely know how to install, setup, run the database and write JSP applications to us the database in the background so these security vulnerabilities are beyond the scope of my own understanding of the database from a mere admin/user level. I am going to paste below the feedback I received concerning the vulnerabilities of the database in hopes that The PostgreSQL Global Development Group would consider looking into each stated flaw. I believe that resolution of these vulnerabilities would be a major achievement of our database management system and possibly open the software up to more government acceptance and utilization, which I believe it is lacking. Here are the vulnerabilities that were stated (each one has a special Common Vulnerabilities and Exposures (CVE)codes that this IS team had assigned): CVE-2005-0245 Buffer overflow in gram.y for PostgreSQL 8.0.0 and earlier may allow attackers to execute arbitrary code via a large number of arguments to a refcursor function (gram.y), which leads to a heap-based buffer overflow, a different vulnerability than CVE-2005-0247. CVE-2005-0244 PostgreSQL 8.0.0 and earlier allows local users to bypass the EXECUTE permission check for functions by using the CREATE AGGREGATE command. CVE-2005-0227 PostgreSQL (pgsql) 7.4.x, 7.2.x, and other versions allows local users to load arbitrary shared libraries and execute code via the LOAD extension. CVE-2005-0246 The intagg contrib module for PostgreSQL 8.0.0 and earlier allows attackers to cause a denial of service (crash) via crafted arrays. CVE-2005-0247 Multiple buffer overflows in gram.y for PostgreSQL 8.0.1 and earlier may allow attackers to execute arbitrary code via (1) a large number of variables in a SQL statement being handled by the read_sql_construct function, (2) a large number of INTO variables in a SELECT statement being handled by the make_select_stmt function, (3) alarge number of arbitrary variables in a SELECT statement being handled by the make_select_stmt function, and (4) a large number of INTO variables in a FETCH statement being handled by the make_fetch_stmt function, a different set of vulnerabilities than CVE-2005-0245. CVE-2005-1409 PostgreSQL 7.3.x through 8.0.x gives public EXECUTE access to certain character conversion functions, which allows unprivileged users to call those functions with malicious values, with unknown impact, aka the "Character conversion vulnerability CVE-2005-1410 - The tsearch2 module in PostgreSQL 7.4 through 8.0.x declares the (1) dex_init, (2) snb_en_init, (3) snb_ru_init, (4)spell_init, and (5) syn_init functions as "internal" even when they do not take an internal argument, which allows attackers to cause a denial of service (application crash) and possibly have other impacts via SQL commands that call other functions that accept internal arguments. Ferindo ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] Huge query stalls at PARSE/BIND stage (2)
... continued ... So that is the query. The destination table looks like this: Table "public.pws_stats_case" Column| Type | Modifiers -+---+--- batch_id| integer | csid| integer | not null year| integer | month | integer | case_upload_date| date | num_live| integer | bal_live| numeric(12,2) | amt_live| numeric(12,2) | fees_live | numeric(12,2) | num_arrange | integer | bal_arrange | numeric(12,2) | amt_arrange | numeric(12,2) | fees_arrange| numeric(12,2) | num_trace | integer | bal_trace | numeric(12,2) | amt_trace | numeric(12,2) | fees_trace | numeric(12,2) | num_successful_remitted | integer | bal_successful_remitted | numeric(12,2) | amt_successful_remitted | numeric(12,2) | fees_successful_remitted| numeric(12,2) | num_expired | integer | bal_expired | numeric(12,2) | amt_expired | numeric(12,2) | fees_expired| numeric(12,2) | num_fullypaid | integer | bal_fullypaid | numeric(12,2) | amt_fullypaid | numeric(12,2) | fees_fullypaid | numeric(12,2) | num_successful | integer | bal_successful | numeric(12,2) | amt_successful | numeric(12,2) | fees_successful | numeric(12,2) | num_our_hold| integer | bal_our_hold| numeric(12,2) | amt_our_hold| numeric(12,2) | fees_our_hold | numeric(12,2) | num_client_hold | integer | bal_client_hold | numeric(12,2) | amt_client_hold | numeric(12,2) | fees_client_hold| numeric(12,2) | num_hold| integer | bal_hold| numeric(12,2) | amt_hold| numeric(12,2) | fees_hold | numeric(12,2) | num_allocated | integer | bal_allocated | numeric(12,2) | amt_allocated | numeric(12,2) | fees_allocated | numeric(12,2) | num_30days | integer | bal_30days | numeric(12,2) | amt_30days | numeric(12,2) | fees_30days | numeric(12,2) | num_60days | integer | bal_60days | numeric(12,2) | amt_60days | numeric(12,2) | fees_60days | numeric(12,2) | num_90days | integer | bal_90days | numeric(12,2) | amt_90days | numeric(12,2) | fees_90days | numeric(12,2) | num_365days | integer | bal_365days | numeric(12,2) | amt_365days | numeric(12,2) | fees_365days| numeric(12,2) | num_returned| integer | bal_returned| numeric(12,2) | amt_returned| numeric(12,2) | fees_returned | numeric(12,2) | num_returned_err| integer | bal_returned_err| numeric(12,2) | amt_returned_err| numeric(12,2) | fees_returned_err | numeric(12,2) | total_num | integer | total_amt | numeric(12,2) | total_bal | numeric(12,2) | total_fees | numeric(12,2) | total_collected | numeric(12,2) | total_num_open | integer | total_amt_open | numeric(12,2) | total_bal_open | numeric(12,2) | total_fees_open | numeric(12,2) | total_collected_open| numeric(12,2) | total_num_closed| integer | total_amt_closed| numeric(12,2) | total_bal_closed| numeric(12,2) | total_fees_closed | numeric(12,2) | total_collected_closed | numeric(12,2) | num_r_uncollectable | integer | amt_r_uncollectable | numeric(12,2) | bal_r_uncollectable | numeric(12,2) | fees_r_uncollectable| numeric(12,2) | num_r_collectable | integer | amt_r_collectable | numeric(12,2) | bal_r_collectable | numeric(12,2) | fees_r_collectable | numeric(12,2) | num_r_requested | integer | amt_r_requested | numeric(12,2) | bal_r_requested | numeric(12,2) | fees_r_requested| numeric(12,2) | fbal_client_hold| numeric(12,2) | f
[BUGS] BUG #2049: pg_dump BACKUP error
The following bug has been logged online: Bug reference: 2049 Logged by: Prakash Suryavanshi Email address: [EMAIL PROTECTED] PostgreSQL version: 7.2 Operating system: Linux Description:pg_dump BACKUP error Details: Respected Sir, I am working on Linux 9.0 and using postgres 7.2 on it. I am facing problem while taking backup of database. I am elaborating situation as follows. Pg_dump commond used to take a backup of my database the command which I used is as follows > pg_dump > system flashes error as follows bash-2.05b$ pg_dump chrome2105 > 2nov1505 pg_dump: ERROR: _mdfd_getrelnfd: cannot open relation ed_accounttype: Permission denied pg_dump: lost synchronization with server, resetting connection pg_dump: SQL command to dump the contents of table "ed_accounttype" failed: PQendcopy() failed. pg_dump: Error message from server: pg_dump: The command was: COPY public.ed_accounttype (accounttypeid, sname, shname, des, active, systemflag, softdelete, datalocationid) TO stdout; bash-2.05b$ Can anybody send me solution how to take backup if above error occured..? This is happening frequently. I had formated the server and again installed Linux then restore database steel problem persist. hopping to get early response. Thanks and regards Prakash Suryavanshi iota technologies ltd., Pune ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Huge query stalls at PARSE/BIND stage (2)
I've been investigating this problem further.
I've tried adding first just 2, then 4 more FULL JOINs to the statement. This works and the statement
gets to INSERT and completes successfully.
If I add 16 further FULL JOINs however, it does not.
Regards,
Matt
P.S. Apologies for the grammar errors in the previous email. I was exhausted yesterday.
IMPORTANT:
This email and any attachments may be confidential and/or privileged. Everything is intended for use of the addressee only. If you are not the
named addressee you must not disseminate, distribute or copy this email. If you receive this email in error please notify the sender by replying
to this email or by telephoning (+44)(0)1325 383876 then delete this message from your system. Philips Collection Services Ltd. ("Philips")
routinely monitors the content of email sent and received on its network, to ensure compliance with its policies and procedures. Although
Philips have taken reasonable precautions to ensure no viruses are present in this email or any files attached to it, it cannot accept
any responsibility for any loss or damage arising from the use of this email or its attachments and advises you to carry out appropriate
virus checks. Philips are not responsible for any changes made to the message after it has been sent nor any files attached to it after
it was sent. Emails that contain encrypted material, program files, are obscene, inflammatory, criminal, offensive, in breach of copyright,
contain a virus or threat to computer systems, appear to be a threat to the company or in breach of company policy may be intercepted and/or deleted.
Philips does not accept any liability for any statements made which are clearly the sender's own and not made on behalf of Philips.
Re: [BUGS] Double sequence increase on single insert with RULE on
Ok :) Then I found the solution in this partical case:
CREATE RULE test1_on_insert AS ON INSERT TO test1 DO INSERT INTO
test_log1 (qid) VALUES ( (SELECT lastval()) );
With this rule all inserts are working as expected :)
Thank you for you advise :)
Sarunas
Michael Fuhr wrote:
On Wed, Nov 16, 2005 at 10:31:10AM +0200, Sarunas Krisciukaitis wrote:
I understand that RULES are like macros.
Strangest thing here is that INSERT to test1 will touch only one
sequence: test1_id_seq.
And it increments test1_id_seq twice during insert with RULE.
Yes, that's a well-known effect of rewriting a query that includes
a call to nextval(). NEW.id in the rule doesn't refer to the value
that's inserted, but rather to the expression that's evaluated to
get that value. Since you didn't provide a value for id it gets
the default: nextval('test1_id_seq'). That expression is used in
both inserts, so the sequence gets incremented twice. See the
archives for numerous past discussions of this behavior.
---(end of broadcast)---
TIP 6: explain analyze is your friend
[BUGS] Huge query stalls at PARSE/BIND stage (1)
(Resending) Hi I have a nightly process which distills a range of statistics from a third-party database into a set of temporary tables, and then from those tables, aggregates and joins these figures into two main tables. Each temporary table contains a moderate number of rows and few columns. The main query is a large series of FULL JOINs and has worked perfectly for a long time. Yesterday I added 20 more join statements to the query (identical to existing statements) and now the main query which would run in <30 seconds, runs indefinitely with the process stuck at "PARSE" in version 7.4, or "BIND" in version 8.0.3. The process is using all available CPU but not a great deal of memory. I've let this process run for over 50 minutes before it is killed by me with signal ABRT. (Terminating the client connection does not stop the process.) If I remove these additional joins the statement perfectly again in <30 seconds. I have upgraded Postgresql from version 7.4 to 8.0.3 but this does not fix the behaviour. The additional tables being full joined are generated with the same java function as the other tables and the only variable being the names of the non-key columns (different temporary tables for different columns of data in the resulting table). The data in the source tables of the additional statements I am adding has an identical size and layout to the source tables from the existing FULL JOIN statements. The only difference with these new tables is that not all of the joined columns are used in the select clause of the main query, some are ignored, whereas in previous tables all columns available are used. Here is the main query: INSERT INTO pws_stats_case ( --- Destination columns batch_id,csid,year,month,case_upload_date, num_live,amt_live,fbal_live,bal_live,fees_live, num_arrange,amt_arrange,fbal_arrange,bal_arrange,fees_arrange, num_fullypaid,amt_fullypaid,fbal_fullypaid,bal_fullypaid,fees_fullypaid, num_successful,amt_successful,fbal_successful,bal_successful,fees_successful, num_trace,amt_trace,fbal_trace,bal_trace,fees_trace, num_expired,amt_expired,fbal_expired,bal_expired,fees_expired, num_our_hold,amt_our_hold,fbal_our_hold,bal_our_hold,fees_our_hold, num_client_hold,amt_client_hold,fbal_client_hold,bal_client_hold,fees_client_hold, num_hold,amt_hold,fbal_hold,bal_hold,fees_hold, num_returned,amt_returned,fbal_returned,bal_returned,fees_returned, num_returned_err,amt_returned_err,fbal_returned_err,bal_returned_err,fees_returned_err, num_30days,amt_30days,fbal_30days,bal_30days,fees_30days, num_60days,amt_60days,fbal_60days,bal_60days,fees_60days, num_90days,amt_90days,fbal_90days,bal_90days,fees_90days, num_365days,amt_365days,fbal_365days,bal_365days,fees_365days, total_num_open,total_amt_open,total_fbal_open,total_bal_open,total_fees_open,total_collected_open, total_num_closed,total_amt_closed,total_fbal_closed,total_bal_closed,total_fees_closed,total_collected_closed, total_num,total_amt,total_fbal,total_bal,total_fees,total_collected, num_r_uncollectable,amt_r_uncollectable,fbal_r_uncollectable,bal_r_uncollectable,fees_r_uncollectable, num_r_collectable,amt_r_collectable,fbal_r_collectable,bal_r_collectable,fees_r_collectable, num_r_requested,amt_r_requested,fbal_r_requested,bal_r_requested,fees_r_requested, num_allocated,amt_allocated,fbal_allocated,bal_allocated,fees_allocated, num_returned_open,amt_returned_open,fbal_returned_open,bal_returned_open,fees_returned_open, num_returned_err_open,bal_returned_err_open,fbal_returned_err_open,amt_returned_err_open,fees_returned_err_open, num_r_uncollectable_open,amt_r_uncollectable_open,bal_r_uncollectable_open,fbal_r_uncollectable_open,fees_r_uncollectable_open, num_r_collectable_open,amt_r_collectable_open,bal_r_collectable_open,fbal_r_collectable_open,fees_r_collectable_open, num_r_requested_open,amt_r_requested_open,bal_r_requested_open,fbal_r_requested_open,fees_r_requested_open, num_returned_closed,amt_returned_closed,fbal_returned_closed,bal_returned_closed,fees_returned_closed, num_returned_err_closed,bal_returned_err_closed,fbal_returned_err_closed,amt_returned_err_closed,fees_returned_err_closed, num_r_uncollectable_closed,amt_r_uncollectable_closed,bal_r_uncollectable_closed,fbal_r_uncollectable_closed,fees_r_uncollectable_closed, num_r_collectable_closed,amt_r_collectable_closed,bal_r_collectable_closed,fbal_r_collectable_closed,fees_r_collectable_closed, num_r_requested_closed,amt_r_requested_closed,bal_r_requested_closed,fbal_r_requested_closed,fees_r_requested_closed, num_open_expired,amt_open_expired,fbal_open_expired,bal_open_expired,fees_open_expired, num_closed_expired,amt_closed_expired,fbal_closed_expired,bal_closed_expired,fees_closed_expired, num_open_successful,amt_open_successful,fbal_open_successful,bal_open_successful,fees_open_successful, num_closed_successful,amt_closed_successful,fbal_closed_successful,b
[BUGS] BUG #2050: Bad plan by using of LIKE
The following bug has been logged online: Bug reference: 2050 Logged by: Johannes Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3 Operating system: i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc (GCC) 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1 Description:Bad plan by using of LIKE Details: I use this table: CREATE TABLE content ( title character(64) NOT NULL, content_htm character(128) NOT NULL, id serial NOT NULL ); ALTER TABLE ONLY content ADD CONSTRAINT p_key PRIMARY KEY (id); CREATE INDEX idx1 ON content USING btree (title); I have filling this with 100 rows by dbmonster and use this statement, after analyze und reindex: SELECT title FROM content WHERE title LIKE 'teane%'; It uses to long time, I compare this with sybase and I was disappointed, but explain shows the reason. EXPLAIN SELECT title FROM content WHERE title LIKE 'teane%'; Seq Scan on content (cost=0.00..75647.59 rows=1 width=68) Filter: (title ~~ 'teane%'::text) Now I change this SQL to: SELECT title FROM content WHERE title >= 'teane' AND title < 'teanez'; I think it means the same but it works very fast by using my index. (1600 ms up to 2 ms !! sybase uses 4 ms) Explain shows the reason: EXPLAIN SELECT title FROM content WHERE title >= 'teane' AND title < 'teanez'; Index Scan using idx1 on content (cost=0.00..4.02 rows=1 width=68) Index Cond: ((title >= 'teane'::bpchar) AND (title < 'teanez'::bpchar)) I'am not sure is this a bug or not, but without some modifications in the postgres.conf the difference are more significant ( 22.530 ms ! to 2 ms). ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2047: Can't get to mirrors
The following bug has been logged online: Bug reference: 2047 Logged by: Jeff Challender Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP Description:Can't get to mirrors Details: Would like to download 8.1 can't access ANY of the mirrors. Tried them all. Can't connect. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2048: initdb hang up
The following bug has been logged online: Bug reference: 2048 Logged by: Acure Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: freebsd Description:initdb hang up Details: I want to upgrade pgsql server from 8.0 to 8.1, but i have troubles with initdb I have instaled pgsql 8.1 from updated ports. As pgsql user i execute initdb : "initdb -U pgsql -W -D datapl" and it stop on : "creating template1 database in tescik/base/1 ..." i have tried to debug with another params - but it's always stop. I have tried to change system seting to : /boot/loader.conf kern.ipc.semmni=256 kern.ipc.semmns=256 /etc/sysctl.conf kern.ipc.somaxconn=4096 kern.ipc.shmmax=146800640 kern.maxfiles=65536 kern.ipc.shmall=65536 Please Help me !! :) ACure ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2050: Bad plan by using of LIKE
On 11/17/05, Johannes <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2050 > Logged by: Johannes > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.3 > Operating system: i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc > (GCC) 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, > pie-8.7.7.1 > Description:Bad plan by using of LIKE > Details: > > I use this table: > CREATE TABLE content ( >title character(64) NOT NULL, >content_htm character(128) NOT NULL, >id serial NOT NULL > ); > ALTER TABLE ONLY content ADD CONSTRAINT p_key PRIMARY KEY (id); > CREATE INDEX idx1 ON content USING btree (title); > > I have filling this with 100 rows by dbmonster and use this statement, > after analyze und reindex: > > SELECT title FROM content WHERE title LIKE 'teane%'; > > It uses to long time, I compare this with sybase > and I was disappointed, but explain shows the reason. > > > EXPLAIN SELECT title FROM content WHERE title LIKE 'teane%'; > Seq Scan on content (cost=0.00..75647.59 rows=1 width=68) > Filter: (title ~~ 'teane%'::text) > > Now I change this SQL to: > SELECT title FROM content WHERE title >= 'teane' AND title < 'teanez'; > > I think it means the same but it works very fast by using my index. > (1600 ms up to 2 ms !! sybase uses 4 ms) > > Explain shows the reason: > > EXPLAIN SELECT title FROM content WHERE title >= 'teane' AND title < > 'teanez'; > Index Scan using idx1 on content (cost=0.00..4.02 rows=1 width=68) > Index Cond: ((title >= 'teane'::bpchar) AND (title < 'teanez'::bpchar)) > > I'am not sure is this a bug or not, but without some modifications in the > postgres.conf the difference are more significant ( 22.530 ms ! to 2 ms). > Maybe you are using a non C-locale? they are known to not use indexes in LIKE querys... instead, you have to create an index with appropiate class operator... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2050: Bad plan by using of LIKE
"Johannes" <[EMAIL PROTECTED]> writes: > EXPLAIN SELECT title FROM content WHERE title LIKE 'teane%'; > Seq Scan on content (cost=0.00..75647.59 rows=1 width=68) >Filter: (title ~~ 'teane%'::text) Apparently you're using a non-C locale. LIKE can only use an index if you're in the C locale or you make the index with a special index operator class. See http://www.postgresql.org/docs/8.0/static/indexes-opclass.html regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2049: pg_dump BACKUP error
"Prakash Suryavanshi" <[EMAIL PROTECTED]> writes: > system flashes error as follows > bash-2.05b$ pg_dump chrome2105 > 2nov1505 > pg_dump: ERROR: _mdfd_getrelnfd: cannot open relation ed_accounttype: > Permission denied You've apparently started the postmaster as the wrong user, or else someone's changed the ownership/permissions of the database files underneath you. Every file within the $PGDATA directory tree ought to be owned by the user that the postmaster runs as, and readable/writable only by that user (mode -rw---, or -rwx-- for directories). Note that pg 7.2 is horribly ancient --- you should update to something newer and still-supported as soon as you get that dump made. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities
"Ferindo Middleton" <[EMAIL PROTECTED]> writes: > This bug report involves more than one proposed bug. I work at a federal > government agency. The information technology division at this agency > refuses to allow the database version 8.0.4 on their network because of > several security vulnerabilities they noticed when testing the software > application. They obviously haven't "tested" anything --- they are merely reading the CVE reports for old Postgres versions. All known CVE problems are resolved in 8.0.4. (If they were actually serious about security, they wouldn't be letting you run Windows 2000 inside their network, but I digress.) regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities
* Ferindo Middleton ([EMAIL PROTECTED]) wrote: > CVE-2005-0245 Buffer overflow in gram.y for PostgreSQL 8.0.0 and earlier > may allow attackers to execute arbitrary code via a large number of > arguments to a refcursor function (gram.y), which leads to a > heap-based buffer overflow, a different vulnerability than CVE-2005-0247. I think this was fixed in 8.0.2... > CVE-2005-0244 PostgreSQL 8.0.0 and earlier allows local users to bypass the > EXECUTE permission check for functions by using the CREATE AGGREGATE > command. This appears to have been fixed in 8.0.1. > CVE-2005-0227 PostgreSQL (pgsql) 7.4.x, 7.2.x, and other versions allows > local users to load arbitrary shared libraries and execute code via the LOAD > extension. The CVE says it only affected pre-8.0 releases and I'm inclined to believe it. > CVE-2005-0246 The intagg contrib module for PostgreSQL 8.0.0 and earlier > allows attackers to cause a denial of service (crash) via crafted arrays. Contrib modules are only an issue if you install them. If you don't need them, don't install them. Don't know if this was fixed but honestly I expect it was, the Postgres folks don't just sit around on their hands when CVE's come out. > CVE-2005-0247 Multiple buffer overflows in gram.y for PostgreSQL 8.0.1 and > earlier may allow attackers to execute arbitrary code via (1) a large number > of variables in a SQL statement being handled by the read_sql_construct > function, (2) a large number of INTO variables in a SELECT statement being > handled by the make_select_stmt function, (3) alarge number of arbitrary > variables in a SELECT statement being handled > by the make_select_stmt function, and (4) a large number of INTO variables > in a FETCH statement being handled by the make_fetch_stmt function, a > different set of vulnerabilities than CVE-2005-0245. Looks like this was fixed in 8.0.2.. > CVE-2005-1409 PostgreSQL 7.3.x through 8.0.x gives public EXECUTE access to > certain character conversion functions, which allows unprivileged users to > call those functions with malicious values, with > unknown impact, aka the "Character conversion vulnerability This appears to have been fixed in 8.0.3. > CVE-2005-1410 - The tsearch2 module in PostgreSQL 7.4 through 8.0.x declares > the (1) dex_init, (2) snb_en_init, (3) snb_ru_init, (4)spell_init, and (5) > syn_init functions as "internal" even when they do > not take an internal argument, which allows attackers to cause a denial of > service (application crash) and possibly have other impacts via SQL commands > that call other functions that accept internal arguments. This appears to have been fixed in 8.0.3. It looks like these were all fixed rather quickly after they were discovered and brought to the attention of the PostgreSQL team. http://www.gsa.gov/networx -> Networx Hosting Center -> NHC User Instructions, Executive Summary. No software is without bugs. It would be foolish to assume that you can deploy a system once and never have to update it for newly discovered security vulnerabilities. If you'd like a comparison to a product they may be allowing elsewhere you might consider looking at Oracle's track record for fixing security issues. It's rather... poor. There have been a number of articles to this affect on bugtraq recently, you shouldn't have too much trouble finding good examples. Enjoy, Stephen signature.asc Description: Digital signature
Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept Postgresql on Network because of Security Vulnerabilities
> Bug reference: 2052 > Logged by: Ferindo Middleton > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0.4 > Operating system: Windows 2000 > Description:Federal Agency Tech Hub Refuses to Accept > Postgresql on > Network because of Security Vulnerabilities > Details: > > This bug report involves more than one proposed bug. I work > at a federal government agency. The information technology > division at this agency refuses to allow the database version > 8.0.4 on their network because of several security > vulnerabilities they noticed when testing the software > application. The database would run on a Windows 2000 > Professional computer system. The division I work for wants > to use the database as a backend to a set Java Server Pages I > developed to be served via Apache Tomcat. My application > works great with PostgreSQL but the problem is getting the IS > team at this agency to accept PostgreSQL db. I know nothing > about hacking PostgreSQL. I am merely know how to install, > setup, run the database and write JSP applications to us the > database in the background so these security vulnerabilities > are beyond the scope of my own understanding of the database > from a mere admin/user level. > > I am going to paste below the feedback I received concerning > the vulnerabilities of the database in hopes that The > PostgreSQL Global Development Group would consider looking > into each stated flaw. I believe that resolution of these > vulnerabilities would be a major achievement of our database > management system and possibly open the software up to more > government acceptance and utilization, which I believe it is lacking. I beleive every single one of these bugs is fixed in the currently available releases. So if you get 8.0.4 or 8.1.0, you're fine for any of these. (Oh, and what *do* they allow? Oracle, for example, has had a *lot* more security vulnerabilities during the same time, some of which aren't even patched yet.. And they can't seriously have a zero-bugs-even-if-fixed policy, because then they couldn't install *anything*...) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2050: Bad plan by using of LIKE
On Thu, Nov 17, 2005 at 06:00:35PM +, Johannes <[EMAIL PROTECTED]> wrote: > SELECT title FROM content WHERE title LIKE 'teane%'; > > It uses to long time, I compare this with sybase > and I was disappointed, but explain shows the reason. > > > EXPLAIN SELECT title FROM content WHERE title LIKE 'teane%'; > Seq Scan on content (cost=0.00..75647.59 rows=1 width=68) >Filter: (title ~~ 'teane%'::text) > > Now I change this SQL to: > SELECT title FROM content WHERE title >= 'teane' AND title < 'teanez'; > > I think it means the same but it works very fast by using my index. > (1600 ms up to 2 ms !! sybase uses 4 ms) You might want to take a look at http://www.postgresql.org/docs/8.1/interactive/indexes-opclass.html and build your indexes on text fields with *_pattern_ops from now on. Does the trick. cheers, bkw ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2047: Can't get to mirrors
Jeff Challender wrote: > Would like to download 8.1 can't access ANY of the mirrors. Tried them all. > Can't connect. Works for me, and for a whole lot of people. Ever considered it may be a problem on your side? -- Alvaro Herrera ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Huge query stalls at PARSE/BIND stage (1)
Matt <[EMAIL PROTECTED]> writes:
>> If you'd be willing to send me a test case off-list, I'd be willing to
>> take a look. A convenient test case from my point of view would be a
>> SQL script that sets up the database plus another one containing the
>> slow query.
> I've created a standalone test case, sending it privately.
Thanks for the test case. The problem turns out to be sloppy coding in
exprTypmod(): it recurses twice on the first argument of a COALESCE,
making for exponential growth in the time needed to process a deep nest
of COALESCE expressions ... which is exactly what your deeply nested
FULL JOINs produce for the join USING variables. The patch attached
fixes it for 8.0.* --- I've committed equivalent fixes as far back as
7.4, where the problem originated.
Moral: sometimes an apparently trivial inefficiency isn't so trivial.
regards, tom lane
Index: src/backend/parser/parse_expr.c
===
RCS file: /cvsroot/pgsql/src/backend/parser/parse_expr.c,v
retrieving revision 1.179.4.2
diff -c -r1.179.4.2 parse_expr.c
*** src/backend/parser/parse_expr.c 25 May 2005 02:17:55 -
1.179.4.2
--- src/backend/parser/parse_expr.c 18 Nov 2005 23:05:21 -
***
*** 1562,1569
int32 typmod;
ListCell *arg;
typmod = exprTypmod((Node *)
linitial(cexpr->args));
! foreach(arg, cexpr->args)
{
Node *e = (Node *) lfirst(arg);
--- 1562,1573
int32 typmod;
ListCell *arg;
+ if (exprType((Node *) linitial(cexpr->args)) !=
coalescetype)
+ return -1;
typmod = exprTypmod((Node *)
linitial(cexpr->args));
! if (typmod < 0)
! return -1; /* no point in trying
harder */
! for_each_cell(arg,
lnext(list_head(cexpr->args)))
{
Node *e = (Node *) lfirst(arg);
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
