I wrote this patch for my system, and it works fine. However, it's a really ugly
workaround. I can publish the source
if anybody is interested.
Am Montag, 26. August 2002 06:33 schrieb Thomas O'Dowd:
Thanks for your feedback Stephan. Seems like a tough fix. Pitty it won't
make it into 7.3. I
On Sun, Aug 25, 2002 at 09:35:24PM -0400, J. R. Nield wrote:
I'm not sure about query result caching or 'relation caching', since the
first would seem to run into problems with concurrent updates, and the
second is sort-of what the buffer cache does.
Query plan caching sounds like a really
On Mon, 26 Aug 2002, Tatsuo Ishii wrote:
Also I notice an announce for release 7.2.3
appeaing on http://www.postgresql.org.
You do? Where?
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL
I think he means 7.2.2...
Chris
On Mon, 26 Aug 2002, Vince Vielhaber wrote:
On Mon, 26 Aug 2002, Tatsuo Ishii wrote:
Also I notice an announce for release 7.2.3
appeaing on http://www.postgresql.org.
You do? Where?
Vince.
--
On Mon, 26 Aug 2002, Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
+ if (!superuser() MyBackendId MaxBackends - ReservedBackends)
+ elog(ERROR, Normal user limit exceeded);
This coding is wrong on its face: the slot number you happen to find has
no
Sir Mordred The Traitor [EMAIL PROTECTED] writes:
template1=# select substring('',2,2147483647);
With CVS HEAD (with database encoding = SQL_ASCII and UNICODE), I get:
nconway=# select substring('',2,2147483647);
ERROR: negative substring length not allowed
With
//@(#) Mordred Labs advisory 0x0007
Release data: 26/08/02
Name: Remote DoS condition in PostgreSQL
Versions affected: all versions
Conditions: entry in a pg_hba.conf file that matches attacker's host.
Risk: average
---[ Description:
Upon connecting to a database, postmaster will fork a new
On 26 Aug 2002 at 14:46, Sir Mordred The Traitor wrote:
[snip]
static int recv_and_check_password0(Port *port) {
int32 len;
char *buf;
if (pq_getint(len, 4) == EOF)
return STATUS_EOF;
len -= 4;
buf = palloc(len); /* len is taken from a packet
Sir Mordred The Traitor [EMAIL PROTECTED] writes:
Note, that the size of palloced memory is taken from the user's input,
which is stupid if you ask me.
Beyond causing an out of memory error during the handshake, I fail to
see how there can be any problem. palloc is considerably more robust
Builds and runs fine under HP/Compaq Tru64 aka Digital Unix aka OSF/1
(this is getting difficult...) version 4.0f/g using standard cc:
template1=# SELECT version();
version
PostgreSQL 7.2.2 on
On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote:
Conditions: entry in a pg_hba.conf file that matches attacker's host.
Risk: average
--[ Solution
Disable network access for untrusted users.
TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by
default.
I
The point is really simple.
Allocate a huge chunk of memory (no sense to cause out of memory error,
as palloc will bail is a requested size 1 gb). The postgres will be ready
to suck your input,
via pg_getbytes(), now in a loop send junk to postgresql.
Of course you can fork a number of processes
-*- Lamar Owen [EMAIL PROTECTED] [ 2002-08-26 15:19 ]:
TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by
default.
I for one thought that it was normal operating procedure to only allow access
to trusted machines; maybe I'm odd in that regard.
Hey, if I can connect
so basically if you are an idiot admin, and leave the postgresql box
open (explicitly opening stuff), and under certian conditions, you can
get DoS'd? hrm, this may not be your biggest problem.
maybe if the dba has a clue and only explicitly allows certian ips
to even route to the box, and then
On Mon, 26 Aug 2002, Mario Weilguni wrote:
Not a lower strength lock, I would, but I'm not so familiar with the postgres
internals. I modified ri-triggers.c to exclude certain tables from the
locking itself (because I know the tables are not updated).
It might help the op of this thread, so
By the way, seems like a beer DOSsed me a little:-).
I've made i mistake in email subject. Remove-remote
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence
Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
I was taking the line that the last slots in the array are
reserved. Those are not going to be taken by non su connections.
But that doesn't do the job, does it? My view of the feature is that
when there are at least MaxBackends
[EMAIL PROTECTED] (Bruce Momjian) wrote
Sir-* does have a point. A valid host in pg_hba.conf can cause DOS by
just connecting over and over, but allocating almost all of the memory
on the machine would affect other applications running on the machine,
even non-networked applications, as
An alarmist style when posting a serious error is a good idea. Hey
guys, I found a possible problem... Does not seem to generate the
needed level of excitement. DOS attacks means that business stops. I
think that should generate a furrowed brow, to say the least.
Obviously people have
Joe Conway [EMAIL PROTECTED] writes:
I'm trying to come up with the best method to pass the query string
columndef, or better yet the tuple description, to the function. Any
suggestions on an approach?
Can't it get it for itself from the results of the query, ie, look at
PQftype() and so on
Any chance we can resolve this before 7.3? I will add it to the TODO
list.
---
Jan Wieck wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Of cource it is nice to have a complete solution
Lamar Owen wrote:
And dealing with a real name would be nice, IMHO. Otherwise we may end up
with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps? :-) Reminds me of
'Uncle George' who did quite a bit for the Alpha port and then disappeared.
Funny you mention that. Now knowing someone's
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
I'm trying to come up with the best method to pass the query string
columndef, or better yet the tuple description, to the function. Any
suggestions on an approach?
Can't it get it for itself from the results of the query, ie, look at
-Original Message-
From: Lamar Owen [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 26, 2002 10:50 AM
To: Bruce Momjian; Tom Lane
Cc: Sir Mordred The Traitor; [EMAIL PROTECTED]
Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007:
Remove DoS in PostgreSQL
On Monday 26
Bruce Momjian [EMAIL PROTECTED] writes:
Any chance we can resolve this before 7.3?
I don't think so; the discussion trailed off without any agreement on
what the behavior should be, and so thinking about how to implement it
seems premature. At this point I think we have more critical issues
to
RPMs for the security bugfix release 7.2.2 are available now for your happy
downloading in two forms and versions on ftp.postgresql.org. You may have to
wait on mirror propagation, which could take a few hours.
For those who want it as close to the previous release as possible, I have
Joe Conway and I have just committed some changes in the internal
representation of Postgres arrays: an element-type-OID field is added to
the array header, and alignment calculations are now done the same way
as in ordinary tuple storage, instead of taking shortcuts. I believe
that these
Is this fixed, and if not, can I have some TODO text?
---
Tom Lane wrote:
If a VACUUM running concurrently with someone else's indexscan were to
delete the index tuple that the indexscan is currently stopped on, then
Bruce Momjian [EMAIL PROTECTED] writes:
Is this fixed, and if not, can I have some TODO text?
It's not fixed. I'd like to fix it for 7.3, but I was hoping someone
would think of a better way to fix it than I did ...
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Could we just block splits of
pages containing pins?
That's not an improvement IMHO. The objection to the fix I suggested is
that it makes it harder for VACUUM to make progress in the presence of
contention. Replacing that with
Have we addressed this? I don't think so.
---
Tom Lane wrote:
Ron Snyder [EMAIL PROTECTED] writes:
May 31 16:11:50 vault pgcvs[2135]: [91] LOG: query: Create Temporary Table
pg_dump_blob_xref(oldOid pg_catalog.oid,
I have been getting the subject message ever since upgrading to 7.2.1. I
tried 7.2.2 with the same thing. It seems to be related to my chkpass type
(see contrib) as it only happens on tables with that type. I tried it on a
new database with a very simple table and still see it. After
On Mon, 26 Aug 2002, Bruce Momjian wrote:
Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
I was taking the line that the last slots in the array are
reserved. Those are not going to be taken by non su connections.
But that doesn't do the job, does it? My view of the
Bruce Momjian [EMAIL PROTECTED] writes:
Have we addressed this? I don't think so.
No, it's not done yet. My inclination is
* Template1 has temp table creation and schema creation disabled
(disallowed to world) by default.
* CREATE DATABASE sets up new databases with temp table creation
Sorry, I am confused. Why can we modify temp's permissions on CREATE
DATABASE but not public's permissions?
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Have we addressed this? I don't think so.
No,
Added to TODO:
* Allow DELETE to handle table aliases for self-joins [delete]
---
Manfred Koizar wrote:
On Mon, 10 Jun 2002 09:56:27 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Does anyone know whether other
I haven't seen any demand for ident DES so I have not applied this
patch. If it becomes a feature request, we can revisit this. Thanks.
---
David M. Kaplan wrote:
Hi,
I added the code to make IDENT authentification
Mostly because a user may explicitly create a database with wanted
permissions, only to have this 'special code' remove them.
I personally intend to immediately revoke permissions on public in
template1, to allow the database owner to grant them as needed.
On Mon, 2002-08-26 at 22:27, Bruce
Oh, so we don't modify public writeability of template1 because the
admin may want to disable write in template1 so all future databases
will have it disabled. I see.
So template1 is writable (yuck) only so databases created from template1
are writeable to world by default. Is that accurate?
On Mon, 2002-08-26 at 23:45, Bruce Momjian wrote:
Oh, so we don't modify public writeability of template1 because the
admin may want to disable write in template1 so all future databases
will have it disabled. I see.
So template1 is writable (yuck) only so databases created from
It just bothers me that of all the databases that should be locked down,
it should be template1, and it isn't by default.
---
Rod Taylor wrote:
On Mon, 2002-08-26 at 23:45, Bruce Momjian wrote:
Oh, so we don't modify
Has this been resolved?
---
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Sorry to nag about this so late, but I fear that the new command SET LOCAL
will cause some confusion later on.
Okay...
SQL
Bruce Momjian [EMAIL PROTECTED] writes:
So template1 is writable (yuck) only so databases created from template1
are writeable to world by default. Is that accurate?
Yup.
I had a probably-harebrained idea about this: the writeability of public
is only a serious issue when it is the default
Bruce Momjian [EMAIL PROTECTED] writes:
Has this been resolved?
I think the resolution was to do nothing.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
I had a good chuckle with this. It is the type of shoot for the moon
idea I would have. Maybe I am rubbing off on you. :-)
The only problem I see with this solution is it makes admins think their
template1 is safe, when it really isn't. That seems more dangerous than
leaving it
Gavin, how are you doing with this. As I remember, the only remaining
issue was where to store the 'drop on commit' information in the
backend. If that is all there is, we can come up with a solution.
---
Gavin Sherry
Bruce,
I have a working patch for this I just need to test it further. It occured
to me that there was a bug with the previous implementation in as much as
it didn't handle situations where the user dropped the temp table in a
transaction block. As such, I have added a flag to the structure
What about Gavin's CREATE OR REPLACE stuff?
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gavin Sherry
Sent: Tuesday, 27 August 2002 1:21 PM
To: Bruce Momjian
Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS]
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
I have been getting the subject message ever since upgrading to 7.2.1. I
tried 7.2.2 with the same thing. It seems to be related to my chkpass type
(see contrib) as it only happens on tables with that type.
FWIW, I couldn't see any problem in CVS
49 matches
Mail list logo
