> > Could the index scan be made to
> > handle cases where the index tuple it was stopped on is gone?
>
> Don't see how. With no equal keys, you could test each tuple you scan
> over to see if it's > the expected key; but that would slow things down
> tremendously I fear. In any case it fails
"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
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]
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 marki
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 wro
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 world-writa
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?
http://www.postgresql.org/
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 defaul
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...
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 mo
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 tem
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?
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 Momj
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
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.
>
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 al
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
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 compil
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
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 t
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 an approach that bloc
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
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
> we'd get a failure when the indexscan resumes and tries to re-find its
> place. (This is the infamous "my bits moved right off the e
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
> --
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
>
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,
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 s
On Monday 26 August 2002 02:51 pm, Dann Corbit wrote:
> I want to make it clear that I think the best way to report a problem is
> with formal, rigorous, complete structure. That structure should be
> known to the receiving body. If there is a procedure or standard form
> for producing the neede
Lamar Owen wrote:
> And, yes, I agree he IS providing a valuable service -- with that I have no
> complaints. But there is a distinct civility and culture to this list, and
> I'd like to see it stay that way.
Well, when someone is a "Sir", we do give them a little more latitude.
(Oh, hold on
> -Original Message-
> From: Lamar Owen [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 26, 2002 11:41 AM
> To: Dann Corbit; Bruce Momjian; Tom Lane
> Cc: Sir Mordred The Traitor; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007:
> Remove DoS in PostgreSQL
[s
With Bear disappearing, I am now unsure of our current SSL code. He
submitted a bunch of patches that seemed to improve our SSL
capabilities, but I am unsure if it is done, and exactly how it was
improved.
Attached is the documentation Bear supplied. I have removed the
interfaces/ssl directory
On Monday 26 August 2002 02:23 pm, Dann Corbit wrote:
> 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
>
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 changes
> 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 ha
[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
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
uploade
I'm looking at modifications to dblink to allow it to make use of table
functions. One item which is very much needed is the ability to define
dblink as returning setof record, so that it can return a tuple as
described at runtime in the query string.
I'm trying to come up with the best method
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
> -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 Mond
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'
On Monday 26 August 2002 12:59 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > It may indeed make sense to put a range check here, but I'm getting
> > tired of hearing the words "dos attack" applied to conditions that
> > cannot be exploited to cause any real problem. All you are
> > accomplishing
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
> > >
Tom Lane wrote:
> 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. pall
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
-*- Sir Mordred The Traitor <[EMAIL PROTECTED]> [ 2002-08-26 15:32 ]:
> >Hey, if I can connect to postmaster I can DoS it quite easily, but
> flooding it
> >with connection requests.
>
> Hm, that's true of course, but now i will do this with a couple of
> connections.
> Lets say, bot on a own
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
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, s
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 c
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).
-Ursprüngliche Nachricht-
Von: Stephan Szabo [mailto:[EMAIL PROTECTED]]
Gesendet
>Hey, if I can connect to postmaster I can DoS it quite easily, but
flooding it
>with connection requests.
Hm, that's true of course, but now i will do this with a couple of
connections.
Lets say, bot on a owned machine, connects to a database,
send a crafted packet,
postgresql will allocate
On Mon, 26 Aug 2002, Mario Weilguni wrote:
> 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.
Which, the for update one or a lower strength lock? In either case,
certainly.
-*- 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
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
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
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 robu
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
//@(#) 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 pr
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 alphaev56-
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 REL7_
"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 - ReservedBacken
On Mon, 26 Aug 2002, Christopher Kings-Lynne wrote:
> *sigh* Someone's marked postgres 7.2.1 as forbidden in FreeBSD ports:
>
> FORBIDDEN= "buffer overruns acknowledged by authors--see
> http://www3.us.postgresql.org/news.html>"
>
> Somewhat of an overreaction...I'm hassling the maintainer a
"..if someone has direct SQL access to your database, they can
already do more damage than what this vulnerability addresses. Specifically
DROP TABLE is available to users with direct SQL command line access..."
That's true of course, but i really dont want to do any damage, i might
even don't
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
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, 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 P
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 rea
66 matches
Mail list logo
