Re: [HACKERS] set search_path failure
Try 'public','s1' perhaps... Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tatsuo Ishii Sent: Monday, 19 August 2002 2:31 PM To: [EMAIL PROTECTED] Subject: [HACKERS] set search_path failure I'm seeing this: test=# create schema s1; CREATE SCHEMA test=# set search_path to 'public, s1'; ERROR: Namespace public, s1 does not exist Am I missing something? -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] set search_path failure
Try 'public','s1' perhaps...
Wao, this is confusing:-)
The man page says:
SET variable { TO | = } { value | 'value' | DEFAULT }
And:
test=# show search_path;
search_path
-
public, s1
(1 row)
So user naturally thinks
set search_path to 'public,s1';
is a correct syntax, no?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Function result cacheing - any comments?
On Sun, 18 Aug 2002, Joe Conway wrote: Philip Warner wrote: So the obvious question is - in the opinion of people who know the code, can a function-result-cache be implemented with a lifetime of a single statement, without butchering the function manager? I don't know if I fully understand what you're proposing, but if I Hi Joe, What Philip seems to be asking for is a mechanism where by if a function is marked as being mathematically deterministic (given a particular set of parameters the same result is always returned -- eg: cos(), sin(), etc) then the result is cached and next time the function is called with the same argument(s) the result is retrieved from the cache instead of the function being run again. If I have got this correct, there is merit in this request. It is a feature of other databases (such as oracle) and SQL99 provides for a differentiation between deterministic and 'possibly non-deterministic' routines. It does not discuss, to my knowledge, how this information should be used. I do not know if it is worth while implementing a deterministic function result cache in Postgres -- I haven't looked at the complexity. Needless to say, it would not be trivial :-). Gavin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function result cacheing - any comments?
What Philip seems to be asking for is a mechanism where by if a function is marked as being mathematically deterministic (given a particular set of parameters the same result is always returned -- eg: cos(), sin(), etc) then the result is cached and next time the function is called with the same argument(s) the result is retrieved from the cache instead of the function being run again. I was under the impression that the sin, cos, tan and like functions are marked non-volatile in the system catalogs and so are evaluated once per transaction only. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Function result cacheing - any comments?
At 17:03 19/08/2002 +1000, Gavin Sherry wrote: What Philip seems to be asking for is a mechanism where by if a function is marked as being mathematically deterministic (given a particular set of parameters the same result is always returned -- eg: cos(), sin(), etc) then the result is cached and next time the function is called with the same argument(s) the result is retrieved from the cache instead of the function being run again. Exactly. But obviously not limited to simple mathematical functions. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function result cacheing - any comments?
What Philip seems to be asking for is a mechanism where by if a function
is marked as being mathematically deterministic (given a
particular set of
parameters the same result is always returned -- eg: cos(), sin(),
etc) then the result is cached and next time the function is called with
the same argument(s) the result is retrieved from the cache
instead of the
function being run again.
Exactly. But obviously not limited to simple mathematical functions.
From 7.3 docs:
http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-createfunction.html
CREATE [ OR REPLACE ] FUNCTION name ( [ argtype [, ...] ] )
RETURNS rettype
{ LANGUAGE langname
| IMMUTABLE | STABLE | VOLATILE
| CALLED ON NULL INPUT | RETURNS NULL ON NULL INPUT | STRICT
| [EXTERNAL] SECURITY INVOKER | [EXTERNAL] SECURITY DEFINER
| AS 'definition'
| AS 'obj_file', 'link_symbol'
} ...
[ WITH ( attribute [, ...] ) ]
And:
IMMUTABLE
STABLE
VOLATILE
These attributes inform the system whether it is safe to replace multiple
evaluations of the function with a single evaluation, for run-time
optimization. At most one choice should be specified. If none of these
appear, VOLATILE is the default assumption.
IMMUTABLE indicates that the function always returns the same result when
given the same argument values; that is, it does not do database lookups or
otherwise use information not directly present in its parameter list. If
this option is given, any call of the function with all-constant arguments
can be immediately replaced with the function value.
STABLE indicates that within a single table scan the function will
consistently return the same result for the same argument values, but that
its result could change across SQL statements. This is the appropriate
selection for functions whose results depend on database lookups, parameter
variables (such as the current time zone), etc. Also note that the
CURRENT_TIMESTAMP family of functions qualify as stable, since their values
do not change within a transaction.
VOLATILE indicates that the function value can change even within a single
table scan, so no optimizations can be made. Relatively few database
functions are volatile in this sense; some examples are random(), currval(),
timeofday(). Note that any function that has side-effects must be classified
volatile, even if its result is quite predictable, to prevent calls from
being optimized away; an example is setval().
So it seems Philip already has what he wants?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Function result cacheing - any comments?
At 15:41 19/08/2002 +0800, Christopher Kings-Lynne wrote: So it seems Philip already has what he wants? I really hope so, but my understanding is that this information is used during optimization, not execution; I want it to be used in execution. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
I'd have thought that if a matching user couldn't be found in the specified database then it would default to searching through the global users? Would be more intuitive... Lee. Bruce Momjian writes: Sample run: $ psql -U postgres test psql: FATAL: user postgres@test does not exist $ psql -U postgres@ test Welcome to psql 7.3devel, the PostgreSQL interactive terminal. ---(end of broadcast)--- TIP 3: 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
[HACKERS] Page type
Having contributed to the need for pg_dump/initdb/restore when
upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make
future transitions easier.
bufpage.h:
typedef struct PageHeaderData
{
...
uint32 pd_type;/* kind and version */
...
}
#define PKIND_HEAP 0x36ae
#define PKIND_BTREEMETA 0x696e
#define PKIND_BTREEINT 0x7552
#define PKIND_BTREELEAF 0x0c9c
#define PKIND_HASH 0xce79
#define PKIND_SEQUENCE 0xd863
#define PKIND_GISTINT 0x5b52
#define PKIND_GISTLEAF 0xde08
#define PKIND_RTREEINT 0x6d17
#define PKIND_RTREELEAF 0x239e
#define PageSetType(page, kind, major, minor) \
(((PageHeader) (page))-pd_type = \
(((kind) 16) | ((major) 12) | ((minor) 8)) \
)
#define PageSetTypeCurrent (page, kind) PageSetType(page, kind, 7, 3)
#define PageGetKind(page) \
PageHeader) (page))-pd_type 0x) 16)
#define PageGetFormat(page) \
PageHeader) (page))-pd_type 0xff00) 8)
#define PageGetFormatMinor(page) \
PageHeader) (page))-pd_type 0x0f00) 8)
#define PageGetFormatMajor(page) \
PageHeader) (page))-pd_type 0xf000) 12)
With most page types this looks like a waste of space (0,05%), which I
hope can be compensated for by greater flexibility in future Postgres
versions. With rtree and gist pd_type replaces a flags field in
OpaqueData (not yet sure about this; will investigate further).
Note, that this or any other kind of version information has to be
implemented at least one release *before* it can be used for the first
time.
Comments? Any chance for this to go into 7.3?
Servus
Manfred
---(end of broadcast)---
TIP 3: 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: [HACKERS] Inheritance
Seems with above you are not able to constrain what qualifies for a supertable row, you would only be able to specify constraints that apply to all it's subtables. Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint to be violated. If a subtable should not have constraint the supertable has, it shouldn't inherit from the supertable. If you want that, you simply need to only create constraints that apply to all tables in the hierarchy. Note that you *can* do this. It should imho be the default behavior. To do otherwise breaks the relational model. That is probably a point of argument. Imho the inheritance feature is something orthogonal to the relational model. It is something else, and thus cannot break the relational model. The SQL inheritance is a class/subclass thing. All tables have instances (==rows) that are not (by itself) related. (Even if they happen to share all attribute values with another row of a supertable.) If you want that, then you need to resort to 3NF (or ROWREF's which iirc is another SQL99 feature). As I understand it, SQL99 has the restriction that a row with the same primary key appearing in a supertable and/or any of its subtables must be the result of a single INSERT statement. Thus, SQL99 doesn't allow what you're saying, if I understand what you're saying. (I'm not sure that I do.) I was not talking about primary key, not all tables have a primary key. If the supertable has a PK, then of course an exact match of columns is not possible in supertable/subtable rows. Am I to take it that you think the inheritance should be inheritance of type information only? That is, if I have supertable A and subtable A', inserting a row into A' does not make a row appear in A? If so, I've got not real problem with that at present, but it's not what postgres currently does, nor would it conform to SQL99. No, not at all. All I am saying is that I want to be able to create a constraint that only applies to the supertable rows, and not the subtable rows. I would *not* want this as default behavior when creating a constraint though. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Function result cacheing - any comments?
Philip Warner [EMAIL PROTECTED] writes: My theory is that if such a piece of code gets a performance gain, then the code is probably worth including, assuming that the function manager does not need to be butchered to achieve the desired goal. Does that sound reasonable? Some real results would certainly bolster your case. So the obvious question is - in the opinion of people who know the code, can a function-result-cache be implemented with a lifetime of a single statement, without butchering the function manager? I'd suggest trying to make it a function call handler. Look at the way Peter did SECURITY DEFINER functions for inspiration. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] set search_path failure
Tatsuo Ishii [EMAIL PROTECTED] writes:
The man page says:
SET variable { TO | = } { value | 'value' | DEFAULT }
So user naturally thinks
set search_path to 'public,s1';
is a correct syntax, no?
The man page needs improvement --- some variables accept a list of
values now. In particular
SET search_path = public, s1;
SET search_path = public, s1;
SET search_path = 'public', 's1';
would all be correct ways of expressing this. The other is not, and
can't be because it would require excluding commas from the set of
characters allowed in quoted schema names.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Inheritance
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote: Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint to be violated. If a subtable should not have constraint the supertable has, it shouldn't inherit from the supertable. If you want that, you simply need to only create constraints that apply to all tables in the hierarchy. Note that you *can* do this. It should imho be the default behavior. So what you're saying is that constraints shouldn't be inherited? To do otherwise breaks the relational model. That is probably a point of argument. Imho the inheritance feature is something orthogonal to the relational model. It is something else, and thus cannot break the relational model. So then constraints must be inherited. The relational model, if I am not incorrect here, says that, given a table definition such as this: CREATE TABLE my_table ( my_key int PRIMARY KEY, my_value text UNIQUE, my_other_value int CHECK (my_other_value 0) ) You will never, ever, when selecting from this table, have returned to you 1. two rows with the same value of my_key but different values for the other columns, 2. two rows with the same value of my_value but different values for the other columns, or 3. a row in which the value of my_other_value is not greater than zero. Breaking these sorts of guarantees under any circumstances really doesn't do it for me; what's the point of having guarantees if they aren't guarantees? As I understand it, SQL99 has the restriction that a row with the same primary key appearing in a supertable and/or any of its subtables must be the result of a single INSERT statement. Thus, SQL99 doesn't allow what you're saying, if I understand what you're saying. (I'm not sure that I do.) I was not talking about primary key, not all tables have a primary key. Well, for those that do Also, I should amend that; I suspect (though I could well be wrong, knowing how screwed up SQL is at times) that this really applies to all candidate keys in the table. (And this is one of my complaints about SQL; it's possible for a table to exist without candidate keys. So much for set theory!) No, not at all. All I am saying is that I want to be able to create a constraint that only applies to the supertable rows, and not the subtable rows. I would strongly object to that. It should not be possible to SELECT data from a table that violates the constraints that that table is guaranteeing on the data. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Page type
Manfred Koizar [EMAIL PROTECTED] writes: Having contributed to the need for pg_dump/initdb/restore when upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make future transitions easier. We do need a page version code but I do not want to waste 4 bytes per page on it. I was intending to steal the low order byte of the pd_pagesize field, thereby restricting page sizes to be multiples of 256 (no big loss). Extant databases would appear to have page version number zero. #define PKIND_HEAP 0x36ae #define PKIND_BTREEMETA 0x696e #define PKIND_BTREEINT 0x7552 #define PKIND_BTREELEAF 0x0c9c #define PKIND_HASH 0xce79 #define PKIND_SEQUENCE 0xd863 #define PKIND_GISTINT 0x5b52 #define PKIND_GISTLEAF 0xde08 #define PKIND_RTREEINT 0x6d17 #define PKIND_RTREELEAF 0x239e This is vast overkill. There might be some value in distinguishing the different kinds of indexes (although I think you can already do that by paying attention to the size of the special space; if not, you'd have to actually look into page zero). We do not need redundant marking of the type of the individual index page. With rtree and gist pd_type replaces a flags field in OpaqueData (not yet sure about this; will investigate further). This is not an improvement, only change for the sake of change. I'd suggest leaving the existing index logic alone. I was intending only to mark 7.3 pages with page version 1 (instead of 0), viewing that as a way of signaling the different header tuple layout. I could also be talked into moving the LP_xxx flags in ItemIds per your suggestion of awhile back --- the efficiency gain from letting offset/size be cleanly aligned is probably marginal, but simply letting hex dumps of pages be more easily readable has some value. And since we're breaking dump tools already this doesn't seem to have much cost. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
Yes, that's the whole point. If I have a constraint on a table, I think it should *never* be possible for that constraint to be violated. If a subtable should not have constraint the supertable has, it shouldn't inherit from the supertable. If you want that, you simply need to only create constraints that apply to all tables in the hierarchy. Note that you *can* do this. It should imho be the default behavior. So what you're saying is that constraints shouldn't be inherited? No. I even said that inheriting should be the default. To do otherwise breaks the relational model. That is probably a point of argument. Imho the inheritance feature is something orthogonal to the relational model. It is something else, and thus cannot break the relational model. So then constraints must be inherited. The relational model, if I am not incorrect here, says that, given a table definition such as this: CREATE TABLE my_table ( my_key int PRIMARY KEY, my_value text UNIQUE, my_other_value int CHECK (my_other_value 0) ) A local constraint should be made obvious from looking at the schema, a possible syntax (probably both ugly :-): CHECK my_table ONLY (my_other_value 0) or CHECK LOCAL (my_other_value 0) You will never, ever, when selecting from this table, have returned to you 1. two rows with the same value of my_key but different values for the other columns, 2. two rows with the same value of my_value but different values for the other columns, or 3. a row in which the value of my_other_value is not greater than zero. Well, that is where I do not think this is flexible enough, and keep in mind that all triggers and rules would then also need such restrictions. I would strongly object to that. Regardless whether your objection is *strong* or not :-) If you don't like the feature (to add a local constraint), don't use it. (Remember you are talking about removing an implemented feature) Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function result cacheing - any comments?
Philip Warner [EMAIL PROTECTED] writes: At 15:41 19/08/2002 +0800, Christopher Kings-Lynne wrote: So it seems Philip already has what he wants? I really hope so, but my understanding is that this information is used during optimization, not execution; I want it to be used in execution. Philip is correct that there is no cacheing of the sort he wants. The existing volatility classifications are somewhat relevant in the sense that an IMMUTABLE or STABLE function would be legal to cache the way he wants ... but the system doesn't do so, it only uses these classifications to drive before-the-query constant folding and decisions about whether indexscans are safe. I would resist any attempt to install cacheing by default for immutable or stable functions. Philip was proposing that function authors would have to explicitly ask for cacheing (ie, add another function property) and that seems a necessary component of an acceptable solution IMHO. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Inheritance
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote: So what you're saying is that constraints shouldn't be inherited? No. I even said that inheriting should be the default. Ah. So you think it should be possible not to inherit constraints. A local constraint should be made obvious from looking at the schema, Ok, this now I could live with. Though I'm not sure that its theoretically very defensible, or worth the effort. Other languages that offer constraints, such as Eiffel (and soon Java), do not allow constraints that are not inherited, as far as I know. Do you have some counterexamples. Well, that is where I do not think this is flexible enough, and keep in mind that all triggers and rules would then also need such restrictions. Yes, all triggers, rules, and everything else would have to be inherited. Regardless whether your objection is *strong* or not :-) If you don't like the feature (to add a local constraint), don't use it. (Remember you are talking about removing an implemented feature) 1. It's not exactly an implemented feature, it's an accident of an incomplete implementation of inheritance done in a certain way. 2. Should we change the way we decide to implement inheritance, perhaps to make fixing the current problems much easier, it might be a lot of work to add this. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inheritance
On Mon, 2002-08-19 at 15:42, Curt Sampson wrote: A local constraint should be made obvious from looking at the schema, Ok, this now I could live with. Though I'm not sure that its theoretically very defensible, or worth the effort. Other languages that offer constraints, such as Eiffel (and soon Java), do not allow constraints that are not inherited, as far as I know. Do you have some counterexamples. In Eiffel, at least, I can say invariant feature_x and redefine feature_x in a descendant class, thus effectively redefining the constraint. If we decide to inherit constraints unconditionally, the application writer can achieve similar flexibility by moving the logic of the constraint into a function whose behaviour depends on which table it is used on. This would put the burden on the application rather than requiring additional syntax in PostgreSQL. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C For every one that asketh receiveth; and he that seeketh findeth; and to him that knocketh it shall be opened. Luke 11:10 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Inheritance
On Mon, 2002-08-19 at 09:42, Curt Sampson wrote: On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote: So what you're saying is that constraints shouldn't be inherited? No. I even said that inheriting should be the default. Ah. So you think it should be possible not to inherit constraints. I've been silent for a bit because I wanted to kick the concept around in my head. After some thought, I say that I support children inheriting constraints. In a more abstract sense, we are really setting conditions for all entities of a given type (class) which must be met to classify as a defined type. Again, in an abstract sense, if I say all candies (type/class, candy) must have sugar (constraint), and I go on to create a subclass of candy which I desire not to have sugar, then there is a fundamental problem. Either I incorrectly identified my problem domain and didn't properly create my entities which address my domain needs or what I'm trying to express really isn't a candy at all. In other words, it sounds like candy should of been a subclass of a more abstract base entity. Likewise, the newly desired class which doesn't have sugar should also inherit from the newly created base class and not be derived from candy at all. A local constraint should be made obvious from looking at the schema, Ok, this now I could live with. Though I'm not sure that its theoretically very defensible, or worth the effort. Other languages that offer constraints, such as Eiffel (and soon Java), do not allow constraints that are not inherited, as far as I know. Do you have some counterexamples. I tend to agree. Constraints should be inherited. See above. Well, that is where I do not think this is flexible enough, and keep in mind that all triggers and rules would then also need such restrictions. Yes, all triggers, rules, and everything else would have to be inherited. Agreed. Regardless whether your objection is *strong* or not :-) If you don't like the feature (to add a local constraint), don't use it. (Remember you are talking about removing an implemented feature) 1. It's not exactly an implemented feature, it's an accident of an incomplete implementation of inheritance done in a certain way. 2. Should we change the way we decide to implement inheritance, perhaps to make fixing the current problems much easier, it might be a lot of work to add this. I'm still trying to figure out if subclasses should be allowed to have localized constraints. I tend to think yes even though it's certainly possible to create seemingly illogical/incompatible/conflicting constraints with parent classes. Then again, my gut feeling is, that's more and an architectural/design issue rather than a fundamental issue with the concept. --Greg Copeland signature.asc Description: This is a digitally signed message part
[HACKERS] Uninstall in contrib/
Hi Guys, It would be really neat if the contrib makefile could run an sql script upon uninstall as well as removing the files. Is that a neat idea? Means it can get rid off all the functions, types, etc. automatically. Unfortunately it's a bit beyond my meagre Makefile abilities... Chris ---(end of broadcast)--- TIP 3: 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: [HACKERS] Remove implicit unique index creation on SERIAL
Since there didn't seem to be anyone objecting to the notion of decoupling UNIQUE from SERIAL, I'm going to go ahead with reviewing/applying Rod's recent patch that does that (and fixes pg_dump to dump 7.3 serials correctly). We can continue to debate about the merits of making additional changes in SERIAL behavior, of course, but this is the one that pg_dump needs. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Uninstall in contrib/
Christopher Kings-Lynne [EMAIL PROTECTED] writes: It would be really neat if the contrib makefile could run an sql script upon uninstall as well as removing the files. Is that a neat idea? Means it can get rid off all the functions, types, etc. automatically. Automatically? How will it determine which database(s) contain the types? What if the databases require password access? It probably would be useful to supply an uninstall SQL script to reverse the effects of the install script, but since we have no idea where the install was run I think we'll have to rely on the DBA to use the script. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Uninstall in contrib/
Automatically? How will it determine which database(s) contain the types? What if the databases require password access? It probably would be useful to supply an uninstall SQL script to reverse the effects of the install script, but since we have no idea where the install was run I think we'll have to rely on the DBA to use the script. Ah - that's probably what I meant. Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL(fwd)
Surprised it took this long.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com http://www.cloudninegifts.com
http://www.meanstreamradio.com http://www.unknown-artists.com
==
-- Forwarded message --
Date: Mon, 19 Aug 2002 15:40:28 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL
// @(#) Mordred Labs Advisory 0x0001
Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: = 7.2
Risk: average
--[ Description:
PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions,
foreign keys, subqueries, triggers, user-defined types and functions.
There exists a stack based buffer overflow in cash_words() function, that
potentially allows an attacker to execute malicious code.
--[ How to reproduce:
psql select cash_words('-70');
pgReadData() -- backend closed the channel unexpectedly.
The connection to the server was lost...
--[ Solution:
Upgrade to version 7.2.1.
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Hi Vince,
Glad he made the advisory for something there's a fix for. :)
Regards and best wishes,
Justin Clift
Vince Vielhaber wrote:
Surprised it took this long.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com http://www.cloudninegifts.com
http://www.meanstreamradio.com http://www.unknown-artists.com
==
-- Forwarded message --
Date: Mon, 19 Aug 2002 15:40:28 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL
// @(#) Mordred Labs Advisory 0x0001
Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: = 7.2
Risk: average
--[ Description:
PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions,
foreign keys, subqueries, triggers, user-defined types and functions.
There exists a stack based buffer overflow in cash_words() function, that
potentially allows an attacker to execute malicious code.
--[ How to reproduce:
psql select cash_words('-70');
pgReadData() -- backend closed the channel unexpectedly.
The connection to the server was lost...
--[ Solution:
Upgrade to version 7.2.1.
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [SECURITY] DoS attack on backend possible
Alvar Freude [EMAIL PROTECTED] writes: What about checking the input for backslash, quote, and double quote (\')? If you are not taking care of those in input then crashing the backend is going to be the least of your worries. with Perl and *using placeholders and bind values*, the application developer has not to worry about this. So, usually I don't check the values in my applications (e.g. if only values between 1 and 5 are allowed and under normal circumstances only these are possible), it's the task of the database (check constraint). That's the idea. It's the job of the database to guarantee data integrety. Obviously, the PostgreSQL developers disagree. If I've got to do all checking in the application anyway, I can almost use MySQL instead. ;-) -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [SECURITY] DoS attack on backend possible
Hi Florian, You guys *definitely* write scarey code. :-( Regards and best wishes, Justin Clift Florian Weimer wrote: Alvar Freude [EMAIL PROTECTED] writes: What about checking the input for backslash, quote, and double quote (\')? If you are not taking care of those in input then crashing the backend is going to be the least of your worries. with Perl and *using placeholders and bind values*, the application developer has not to worry about this. So, usually I don't check the values in my applications (e.g. if only values between 1 and 5 are allowed and under normal circumstances only these are possible), it's the task of the database (check constraint). That's the idea. It's the job of the database to guarantee data integrety. Obviously, the PostgreSQL developers disagree. If I've got to do all checking in the application anyway, I can almost use MySQL instead. ;-) -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 3: 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: [HACKERS] [SECURITY] DoS attack on backend possible
Justin Clift [EMAIL PROTECTED] writes: You guys *definitely* write scarey code. Yes, indeed. My code has a lot of unnecessary and error-prone input validation checks because I don't trust the PostgreSQL parser. That's scary. You don't trust your database that it processes a simple text string, yet you still believe that it keeps all the data you store, although this involves much more complex data structures and algorithms. What a strange asymmetry! -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible
On Mon, 2002-08-19 at 13:14, Florian Weimer wrote: Justin Clift [EMAIL PROTECTED] writes: You guys *definitely* write scarey code. Yes, indeed. My code has a lot of unnecessary and error-prone input validation checks because I don't trust the PostgreSQL parser. Bah.. Check the datatype is close and send it in. Would be much easier to capture database errors if you didn't have to base all error matches on regular expressions (error codes will be nice). ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
OK, with two people now asking to have the patch removed, and with no comment from Thomas, I have removed the patch. This removes XLogDir environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I have also removed the code that dynamically sized xlogdir. ... Back in town... Sorry to hear that this is the way it turned out. It is a bad precedent imho, and I see no way forward on my interest in this area. Hopefully someone else will pick it up; perhaps one of those so vehemently against the details of this? - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift [EMAIL PROTECTED] writes: Glad he made the advisory for something there's a fix for. :) The claim that this bug allows execution of arbitrary code is bogus anyway. The overflow at INT_MIN will clobber the stack, yes, but in an absolutely predetermined way; an attacker will have no opportunity to insert code of his choosing. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SECURITY] DoS attack on backend possible
Florian Weimer [EMAIL PROTECTED] writes: That's the idea. It's the job of the database to guarantee data integrety. Obviously, the PostgreSQL developers disagree. Look: it's an acknowledged bug and it's fixed in current sources. The disagreement is over whether this single bug is sufficient reason to force issuance of a 7.2.2 release. Given that we are within a couple of weeks of going beta for 7.3, the previous decision not to issue a 7.2.2 release will stand, unless something *much* worse than this pops up. Saying or implying that the developers don't care about data integrity does not enhance your credibility. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SECURITY] DoS attack on backend possible
Tom Lane [EMAIL PROTECTED] writes: Saying or implying that the developers don't care about data integrity does not enhance your credibility. Sorry, my fault. Indeed, I didn't check carefully whether the people who go a bit too far in downplaying the problem at hand are in fact PostgreSQL developers. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump, pg_dumpall and createdb privilege
Thomas Swan [EMAIL PROTECTED] writes: 1. create a user with createdb privilege. 2. create a database as that user (allowing that user full reign over that particular db) 3. drop the createdb from the user. 4. pg_dumpall the databases to a single file 5. either use pg_restore or psql infile to restore the databases and it fails. This is a known problem, I remember raising it on hackers several months ago. Is it possible to address this before the 7.3 release or is this concern no longer a problem in the 7.3 branch? It's fixed in CVS. Databases are now created using CREATE DATABASE xxx WITH OWNER yyy: this technique can also be used by the DBA in the first place, avoiding the need to manually add and then remove CREATEDB privs from the new user account. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump, pg_dumpall and createdb privilege
Neil Conway wrote: Thomas Swan [EMAIL PROTECTED] writes: 1. create a user with createdb privilege. 2. create a database as that user (allowing that user full reign over that particular db) 3. drop the createdb from the user. 4. pg_dumpall the databases to a single file 5. either use pg_restore or psql infile to restore the databases and it fails. This is a known problem, I remember raising it on hackers several months ago. If there was a 7.2.2 release it would be wonderful for this to be knocked out, too. Is it possible to address this before the 7.3 release or is this concern no longer a problem in the 7.3 branch? It's fixed in CVS. Databases are now created using CREATE DATABASE xxx WITH OWNER yyy: this technique can also be used by the DBA in the first place, avoiding the need to manually add and then remove CREATEDB privs from the new user account. This is a wonderful thing for those of us running postgresql in a hosting environment.
[HACKERS] ignore me
foobar ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] CREATE CAST WITHOUT FUNCTION should require superuserness?
CREATE CAST WITHOUT FUNCTION is capable of creating binary equivalences that will crash the backend when used (eg, between pass-by-value and pass-by-reference datatypes). The existing restriction that you must own one of the datatypes hardly seems like an adequate permissions check ... especially since any unprivileged user is able to create his own datatypes. I think it might be a good idea to require superuser permissions to create a binary-equivalence cast. This is equivalent to the permissions you'd need to create a dummy C function so as to cause the same failure without using WITHOUT FUNCTION. Comments? Also, in the present state of the code a WITHOUT FUNCTION cast does not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find it. Is this intentional, or just an oversight? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible
[EMAIL PROTECTED] (Florian Weimer) wrote
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in
input then crashing the backend is going to be the least of your
worries.
with Perl and *using placeholders and bind values*, the application
developer has not to worry about this. So, usually I don't check the
values in my applications (e.g. if only values between 1 and 5 are
allowed and under normal circumstances only these are possible), it's
the task of the database (check constraint).
That's the idea. It's the job of the database to guarantee data
integrety.
Obviously, the PostgreSQL developers disagree. If I've got to do all
checking in the application anyway, I can almost use MySQL
instead. ;-)
perhaps I did not express myself very well.
if you are going to be passing any user input to the database, you
must/should validate in some manner before blindly passing it to the db.
The db can and should guarantee data integrity, but the database cannot
read your mind when it comes to how you structure your queries.
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash. at some point this has to happen, because
INSERT INTO db (name) VALUES ('user'name');
is not a valid query.
The other thing is i think you are stretching the db integrity
checking argument a little too far. Its the db's responsibility to make
sure only valid data is stored, but its not the db's responsibility to
directly interact with your end users -- this is the job of your
application and interface. If you insert a new record and there is a
constraint violation, how is your application supposed to know what
illegal value(s) is/are causing it? How are you supposed to convey the
proper information to your user to get the input you are looking for?
Besides all that, and i dont mean to insult you, but your just plain
stupid if you blindly pass user inputted data to your db. For that
matter, your stupid if you blindly accept user input in any programming
without checking it at some level.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote: integrate or move to gborg libpqxx, Pg:DBD It's no longer my CVS home tree... Is there something I can/should do for this? Jeroen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Vince, Do you reckon it's worth you responding to Sir Mordred and pointing out that he overstated the vulnerability? :-) Regards and best wishes, Justin Clift Tom Lane wrote: Justin Clift [EMAIL PROTECTED] writes: Glad he made the advisory for something there's a fix for. :) The claim that this bug allows execution of arbitrary code is bogus anyway. The overflow at INT_MIN will clobber the stack, yes, but in an absolutely predetermined way; an attacker will have no opportunity to insert code of his choosing. regards, tom lane -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002, Justin Clift wrote: Vince, Do you reckon it's worth you responding to Sir Mordred and pointing out that he overstated the vulnerability? Not me. Tom (pref) or Marc would be the proper respondent. :-) Regards and best wishes, Justin Clift Tom Lane wrote: Justin Clift [EMAIL PROTECTED] writes: Glad he made the advisory for something there's a fix for. :) The claim that this bug allows execution of arbitrary code is bogus anyway. The overflow at INT_MIN will clobber the stack, yes, but in an absolutely predetermined way; an attacker will have no opportunity to insert code of his choosing. regards, tom lane Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the project. It is his code, and if he would add me as an admin, that would help. I am CC'ing him. --- Marc G. Fournier wrote: On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Remove implicit unique index creation on SERIAL columns?
Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I agree 100%. If you want an index, unique constraint, or primary key on a SERIAL, I think you should explicitly add it. SERIAL should give me a column that automatically increments -- no more, no less. Hmm, do you also want to eliminate the implicit NOT NULL constraint? I think that efficiency and orthogonality are adequate reasons for dissociating UNIQUE from SERIAL. The efficiency argument is pretty weak in the case of the NOT NULL part, though, so maybe backwards compatibility should win out there. To be honest I wasn't thinking about NOT NULL. I'd agree with leaving that in place. Maybe I should restate my comment above: SERIAL should give me a column that automatically increments -- no more, no less -- and it should not allow me to override the value that it gives. Hence an implicit NOT NULL, but also an implicit rejection of a manual insert/update of that field (how hard would this be to do?). If don't understand. We already have a unique index on the SERIAL column, so why bother rejecting an insert/update that supplies the value? We need the column to be unique, and that is forced, but why prevent _any_ unique value from being used. Clearly NULL is not a valid value and should be prevented with NOT NULL. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002, Justin Clift wrote: Vince, Do you reckon it's worth you responding to Sir Mordred and pointing out that he overstated the vulnerability? Not me. Tom (pref) or Marc would be the proper respondent. Has it actually been fixed? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Christopher Kings-Lynne wrote: On Tue, 20 Aug 2002, Justin Clift wrote: Vince, Do you reckon it's worth you responding to Sir Mordred and pointing out that he overstated the vulnerability? Not me. Tom (pref) or Marc would be the proper respondent. Has it actually been fixed? The TODO list only mentions the cash_out(2) problem, whilst the email archives mention them both. From the info still around, this looks to mean that the cash_words() problem was fixed, but the cash_out() problem was harder to fix. Tom/Bruce, is that correct? + Justin Chris -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Page type
I didn't follow the index part completely, but will heap and index pages have the version info in the same offset? Will there be a way to easily identify an index page vs. a heap page. --- Tom Lane wrote: Manfred Koizar [EMAIL PROTECTED] writes: Having contributed to the need for pg_dump/initdb/restore when upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make future transitions easier. We do need a page version code but I do not want to waste 4 bytes per page on it. I was intending to steal the low order byte of the pd_pagesize field, thereby restricting page sizes to be multiples of 256 (no big loss). Extant databases would appear to have page version number zero. #define PKIND_HEAP 0x36ae #define PKIND_BTREEMETA 0x696e #define PKIND_BTREEINT 0x7552 #define PKIND_BTREELEAF 0x0c9c #define PKIND_HASH 0xce79 #define PKIND_SEQUENCE 0xd863 #define PKIND_GISTINT 0x5b52 #define PKIND_GISTLEAF 0xde08 #define PKIND_RTREEINT 0x6d17 #define PKIND_RTREELEAF 0x239e This is vast overkill. There might be some value in distinguishing the different kinds of indexes (although I think you can already do that by paying attention to the size of the special space; if not, you'd have to actually look into page zero). We do not need redundant marking of the type of the individual index page. With rtree and gist pd_type replaces a flags field in OpaqueData (not yet sure about this; will investigate further). This is not an improvement, only change for the sake of change. I'd suggest leaving the existing index logic alone. I was intending only to mark 7.3 pages with page version 1 (instead of 0), viewing that as a way of signaling the different header tuple layout. I could also be talked into moving the LP_xxx flags in ItemIds per your suggestion of awhile back --- the efficiency gain from letting offset/size be cleanly aligned is probably marginal, but simply letting hex dumps of pages be more easily readable has some value. And since we're breaking dump tools already this doesn't seem to have much cost. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Yes, perhaps a bad precedent. I have very rarely done this. I do have the patch here if anyone wants to use it. My guess is if someone implements it, it will be done only in initdb, and use symlinks, which you and Marc don't like, so we may be best leaving it undone for 7.3 and returning with a clear slate in 7.4. --- Thomas Lockhart wrote: OK, with two people now asking to have the patch removed, and with no comment from Thomas, I have removed the patch. This removes XLogDir environment variable, and -X postmaster/postgres/initdb/pg_ctl flag. I have also removed the code that dynamically sized xlogdir. ... Back in town... Sorry to hear that this is the way it turned out. It is a bad precedent imho, and I see no way forward on my interest in this area. Hopefully someone else will pick it up; perhaps one of those so vehemently against the details of this? - Thomas -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Vince Vielhaber wrote:
Surprised it took this long.
Yes, me too, and it says the solution is to upgrade to 7.2.1. Nope.
-- Forwarded message --
Date: Mon, 19 Aug 2002 15:40:28 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL
// @(#) Mordred Labs Advisory 0x0001
Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: = 7.2
Risk: average
--[ Description:
PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions,
foreign keys, subqueries, triggers, user-defined types and functions.
There exists a stack based buffer overflow in cash_words() function, that
potentially allows an attacker to execute malicious code.
--[ How to reproduce:
psql select cash_words('-70');
pgReadData() -- backend closed the channel unexpectedly.
The connection to the server was lost...
--[ Solution:
Upgrade to version 7.2.1.
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: 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: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift wrote: Hi Vince, Glad he made the advisory for something there's a fix for. :) Oh, I see he jumpe on cash_words() and didn't mention cash_out. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Has it actually been fixed? I couldn't reproduce a problem with his example. The buffer size in cash_words is awfully tight though --- it's dimensioned 128 which looks like a round number rather than a carefully calculated one, and the required size is at least 115. I was thinking of bumping it up to 256 just to be sure. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift wrote:
Christopher Kings-Lynne wrote:
On Tue, 20 Aug 2002, Justin Clift wrote:
Vince,
Do you reckon it's worth you responding to Sir Mordred and pointing
out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper respondent.
Has it actually been fixed?
The TODO list only mentions the cash_out(2) problem, whilst the email
archives mention them both.
From the info still around, this looks to mean that the cash_words()
problem was fixed, but the cash_out() problem was harder to fix.
Tom/Bruce, is that correct?
Looks like cash_words is fixed in current CVS, so I guess in 7.2.1:
Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
test= select cash_words('-70');
cash_words
Minus twenty one million four hundred seventy four thousand eight
hundred thirty six dollars and forty eight cents
(1 row)
Looks like cash_out still bombs:
test= select cash_out(2);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Page type
Bruce Momjian [EMAIL PROTECTED] writes: I didn't follow the index part completely, but will heap and index pages have the version info in the same offset? Sure, low byte of pd_pagesize. Will there be a way to easily identify an index page vs. a heap page. There already is: heap pages have zero special-space size, indexes don't. regards, tom lane ---(end of broadcast)--- TIP 3: 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: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift [EMAIL PROTECTED] writes: From the info still around, this looks to mean that the cash_words() problem was fixed, but the cash_out() problem was harder to fix. Tom/Bruce, is that correct? The cash_out problem can't really be fixed until we do something about subdividing type opaque into multiple pseudo-types with more carefully defined meanings. cash_out is declared cash_out(opaque) which does not really mean that it accepts any input type ... but one of the several meanings of opaque is accepts any type, so the parser doesn't reject cash_out(2). I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Thomas Lockhart [EMAIL PROTECTED] writes: Sorry to hear that this is the way it turned out. It is a bad precedent imho, and I see no way forward on my interest in this area. Hopefully someone else will pick it up; perhaps one of those so vehemently against the details of this? I said I would be willing to make initdb create a symlink given a -X switch; if you don't want to pick it up then I will do that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Oh, sorry. I will do it now. --- Marc G. Fournier wrote: We're talking about libpq++, not libpqxx :) On Mon, 19 Aug 2002, Bruce Momjian wrote: Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the project. It is his code, and if he would add me as an admin, that would help. I am CC'ing him. --- Marc G. Fournier wrote: On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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: [HACKERS] Remove implicit unique index creation on SERIAL columns?
On Mon, 19 Aug 2002, Bruce Momjian wrote: Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I agree 100%. If you want an index, unique constraint, or primary key on a SERIAL, I think you should explicitly add it. SERIAL should give me a column that automatically increments -- no more, no less. Hmm, do you also want to eliminate the implicit NOT NULL constraint? I think that efficiency and orthogonality are adequate reasons for dissociating UNIQUE from SERIAL. The efficiency argument is pretty weak in the case of the NOT NULL part, though, so maybe backwards compatibility should win out there. To be honest I wasn't thinking about NOT NULL. I'd agree with leaving that in place. Maybe I should restate my comment above: SERIAL should give me a column that automatically increments -- no more, no less -- and it should not allow me to override the value that it gives. Hence an implicit NOT NULL, but also an implicit rejection of a manual insert/update of that field (how hard would this be to do?). If don't understand. We already have a unique index on the SERIAL column, so why bother rejecting an insert/update that supplies the value? We need the column to be unique, and that is forced, but why prevent _any_ unique value from being used. One reason is that the sequence won't respect those inserted values and you'll get uniqueness errors on statements that don't give a value for the column where you'd expect to be getting a working autogenerated value. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Removing Libraries (Was: Re: [HACKERS] Open 7.3 issues)
Done. Called libpq++. --- Bruce Momjian wrote: Oh, sorry. I will do it now. --- Marc G. Fournier wrote: We're talking about libpq++, not libpqxx :) On Mon, 19 Aug 2002, Bruce Momjian wrote: Actually, I think Jeroen T. Vermeulen [EMAIL PROTECTED] should create the project. It is his code, and if he would add me as an admin, that would help. I am CC'ing him. --- Marc G. Fournier wrote: On Sun, 18 Aug 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Okay, here is what I'd like to suggest ... Bruce, let's start off really simple ... go create a project for libpq++ (I believe someone even volunteered to maintain it?) and let me know once created, and I'll move the CVS directory over for libpq++ and out of the pgsql-server directory I said that I would lend a hand in preparing the build system, but I'm not going to start a project on gborg if I have to agree to a two-page terms of service agreement and I don't get to choose the exact wording of the license. I didn't ask you to, I asked Bruce to ... and the license should stay BSD ... -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift [EMAIL PROTECTED] writes: Hang on, you seem to be suggesting we release a major new upgrade, with major new functionality, knowing it contains a way to trivially crash the backend. This particular hole has been in *every* release since Postgres 1.01. I'm really not interested in responding to any argument that we cannot release 7.3 until we have fixed everything that could be labeled a DOS threat. 7.3 already contains a bunch of bug fixes; shall we postpone releasing those because there are other unfixed bugs? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
test= select cash_words('-70');
Minus twenty one million four hundred seventy four thousand eight
hundred thirty six dollars and forty eight cents
It doesn't crash - but it sure is giving the wrong answer ;)
Well, yeah, it's only a 32-bit storage value. Overflow per se is not
the issue here. (One reason why I'm not excited about fixing this on an
emergency basis is that I can't believe anyone is using the money type
for any mission-critical applications... it's too limited.)
regards, tom lane
---(end of broadcast)---
TIP 3: 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: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Hang on, you seem to be suggesting we release a major new upgrade, with major new functionality, knowing it contains a way to trivially crash the backend. Err.. hang on. What happened to our reputation for quality and releasing when it's ready? Since when were we Microsoft-ized? I personally agree with Justin that it should be fixed for 7.3 (just imagine all those people selling colo postgres services). There should be a 7.2.2 as well that fixes the date parser problem. However, if you let people just run anything they want on your server (eg. select cash_out(2);) then you're already in a world of pain because they can quite easily DOS you by doing large, expensive queries, creating 1000 billion row tables, etc., etc. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote: I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Hang on, you seem to be suggesting we release a major new upgrade, with major new functionality, knowing it contains a way to trivially crash the backend. Err.. hang on. What happened to our reputation for quality and releasing when it's ready? Since when were we Microsoft-ized? I personally agree with Justin that it should be fixed for 7.3 (just imagine all those people selling colo postgres services). There should be a 7.2.2 as well that fixes the date parser problem. Has anyone actually considered the time required to make the appropriate fix (clean up use of OPAQUE)? I don't think this bug is worthy of pushing the 7.3 release out a few weeks. The simple fix is to drop the money type entirely as it serves few purposes -- but there are some who use it. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift [EMAIL PROTECTED] writes: Tom Lane wrote: This particular hole has been in *every* release since Postgres 1.01. How many releases have we known about this and still done a major release? Several; a quick glance in the archives shows this has been on the TODO list since 7.0.something. I really have zero patience for arguments that problem FOO is so bad that we should drop everything else until we've fixed it. There are too many possible candidates for problem FOO, and there are still only 24 hours in the day. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Rod Taylor dijo: The simple fix is to drop the money type entirely as it serves few purposes -- but there are some who use it. There are a lot of other functions that cause the same problem. Just dropping or fixing cash_out is not the solution. -- Alvaro Herrera (alvherre[a]atentus.com) One man's impedance mismatch is another man's layer of abstraction. (Lincoln Yeoh) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] XLogDir
Revert. The XLogDir change was incomplete and basically useless to start with ... Yea, but it was tied into the PGXLOG commit. Thomas, what are we doing with that? Why ask me? - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002 13:40, Justin Clift wrote: [snip] For example, thinking about something like the various ISP's around who host PostgreSQL databases; how much effort would it take to fix the vulnerabilities that let someone with remote access, but no ability to run a trusted language, take out the backend? I believe its been said before, in this forum no less, that PostgreSQL should focus on its primary role as an RDBMS and not be paranoid about security. I believe it was the thread on SSL connections, and Tom suggested a simple ssh tunnel or vpn. Of course, lets not leave the door wide open, but perhaps the developer's time would be better spent on features such as schemas and replication. I know that all of my clients have their databases behind several layers of firewalls, and taking advantage of a vulnerability such as this remotely is extremely difficult. Finally, question the due dilligence process that selects an ISP partner who would leave a database open to the world, even if they run unbreakable Oracle :) Cheers Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Hi Mark, Mark Pritchard wrote: snip I believe its been said before, in this forum no less, that PostgreSQL should focus on its primary role as an RDBMS and not be paranoid about security. I believe it was the thread on SSL connections, and Tom suggested a simple ssh tunnel or vpn. Of course, lets not leave the door wide open, but perhaps the developer's time would be better spent on features such as schemas and replication. What you're saying has a lot of merit, these are important features. However, part of our reputation is as being a higher-end, more powerful, more mature, database offering than other solutions around. As Tom pointed out, we've already had several releases without getting rid of this OPAQUE DOS bug, and as pointed out he also really doesn't have the patience for fixing it (yet). Was hoping we could get serious bugs fixed sooner rather than later, otherwise I'm afraid of us just adding more bugs over time until we start to affect our having come good reputation. I know that all of my clients have their databases behind several layers of firewalls, and taking advantage of a vulnerability such as this remotely is extremely difficult. Totally agreed. Lots of higher end or corporate places are, and that's not a bad thing in any way. For your clients, this particular bugfix doesn't sounds like its necessary. Finally, question the due dilligence process that selects an ISP partner who would leave a database open to the world, even if they run unbreakable Oracle :) This is the one point of yours I don't feel you've quite got down pat. Err... *why* is it safe to leave a HTTP, SSH, IMAP, etc server open to the world (configured correctly of course), but somehow fundamentally wrong to leave a database server open to the world. If we've got a product without these bugs, there wouldnt be a security vulnerability would there? The schema side of things could be *really* useful for ISPs' for example, yet a large number of them probably wouldn't be so comfortable having PostgreSQL available for their clients whilst knowing that these kinds of DOS bugs exists. Mentally, it's not a good thing. Not trying to be a pain here, but instead trying to keep our QA level up. :) Regards and best wishes, Justin Clift Cheers Mark -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Mark Pritchard [EMAIL PROTECTED] writes: I believe its been said before, in this forum no less, that PostgreSQL should focus on its primary role as an RDBMS and not be paranoid about security. I believe it was the thread on SSL connections, and Tom suggested a simple ssh tunnel or vpn. I'd say the two issues are pretty different. IMHO, buffer overruns and similar security problems are just a special class of software bug (it's interesting to note that most of the buffer overruns have been found in the less-maintained parts of the system, like the cash type or contrib/). Therefore, the justification for fixing buffer overruns (and avoiding them in the first place) is the same as for fixing other kinds of bugs: it makes the system more reliable. On the other hand, adding something like SSL tends to make the system more complex (and therefore *less* reliable). There may or may not be a pay-off from a user's POV, but it's not the clear win that avoiding buffer overruns is, IMHO. Of course, lets not leave the door wide open, but perhaps the developer's time would be better spent on features such as schemas and replication. It's probably worth noting that the barrier to entry for fixing buffer overruns or doing a code audit is much, much lower than for implementing advanced features like schemas or replication. The main thing that auditing code requires is time, rather than coding skill/knowledge. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
As Tom pointed out, we've already had several releases without getting rid of this OPAQUE DOS bug, and as pointed out he also really doesn't have the patience for fixing it (yet). Was hoping we could get serious bugs fixed sooner rather than later, otherwise I'm afraid of us just adding more bugs over time until we start to affect our having come good reputation. Getting a buggy rep on BugTraq has got to be a Bad Thing. We already have enough trouble competing with MySQL mindshare, and they haven't had BugTraq problems. Chris ---(end of broadcast)--- TIP 3: 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: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
-Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 10:22 PM To: Mark Pritchard Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne; [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in Mark Pritchard [EMAIL PROTECTED] writes: I believe its been said before, in this forum no less, that PostgreSQL should focus on its primary role as an RDBMS and not be paranoid about security. I believe it was the thread on SSL connections, and Tom suggested a simple ssh tunnel or vpn. I'd say the two issues are pretty different. IMHO, buffer overruns and similar security problems are just a special class of software bug (it's interesting to note that most of the buffer overruns have been found in the less-maintained parts of the system, like the cash type or contrib/). Therefore, the justification for fixing buffer overruns (and avoiding them in the first place) is the same as for fixing other kinds of bugs: it makes the system more reliable. On the other hand, adding something like SSL tends to make the system more complex (and therefore *less* reliable). There may or may not be a pay-off from a user's POV, but it's not the clear win that avoiding buffer overruns is, IMHO. Of course, lets not leave the door wide open, but perhaps the developer's time would be better spent on features such as schemas and replication. It's probably worth noting that the barrier to entry for fixing buffer overruns or doing a code audit is much, much lower than for implementing advanced features like schemas or replication. The main thing that auditing code requires is time, rather than coding skill/knowledge. Most computer virus problems are caused by buffer overrun. Someone decided it wasn't very important. Some computer viruses have caused billions of dollars in damage. Sounds important to me. Please try our database. Someday, we hope to close off all the virus entry points, but right now, we figure it isn't too important. Will you trust your multi-million dollar database to someone who says the above? I think the priorities are upside down. Any *known* buffer-overrun _must_ be repaired, and as quickly as possible. And potential overruns should be identified. A grep for memcpy, strcpy, gets, etc. should hunt down most of them. A known buffer overrun should fill the designer of a product with abject terror. And I really mean that, literally. If you *know* of a buffer overrun, and simply decide not to fix it, that sounds very negligent to me. For a public project like PostgreSQL, there is probably very little liability for the programmers, but I am thinking of the damage that can be inflicted upon potential clients using the database. ---(end of broadcast)--- TIP 3: 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
[HACKERS] regression test failures in CVS HEAD
The 'type_sanity' and 'domain' regression tests seem to fail with CVS
HEAD. Here's the diff:
*** ./expected/type_sanity.out Sun Aug 4 15:48:11 2002
--- ./results/type_sanity.out Tue Aug 20 01:32:35 2002
***
*** 16,22
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE (p1.typlen = 0 AND p1.typlen != -1) OR
! (p1.typtype != 'b' AND p1.typtype != 'c' AND p1.typtype != 'p') OR
NOT p1.typisdefined OR
(p1.typalign != 'c' AND p1.typalign != 's' AND
p1.typalign != 'i' AND p1.typalign != 'd') OR
--- 16,22
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE (p1.typlen = 0 AND p1.typlen != -1) OR
! p1.typtype not in('b', 'c', 'd', 'p') OR
NOT p1.typisdefined OR
(p1.typalign != 'c' AND p1.typalign != 's' AND
p1.typalign != 'i' AND p1.typalign != 'd') OR
***
*** 60,66
-- NOTE: as of 7.3, this check finds SET, smgr, and unknown.
SELECT p1.oid, p1.typname
FROM pg_type as p1
! WHERE p1.typtype = 'b' AND p1.typname NOT LIKE '\\_%' AND NOT EXISTS
(SELECT 1 FROM pg_type as p2
WHERE p2.typname = ('_' || p1.typname)::name AND
p2.typelem = p1.oid);
--- 60,66
-- NOTE: as of 7.3, this check finds SET, smgr, and unknown.
SELECT p1.oid, p1.typname
FROM pg_type as p1
! WHERE p1.typtype in ('b','d') AND p1.typname NOT LIKE '\\_%' AND NOT EXISTS
(SELECT 1 FROM pg_type as p2
WHERE p2.typname = ('_' || p1.typname)::name AND
p2.typelem = p1.oid);
==
*** ./expected/domain.out Fri Jul 12 14:43:19 2002
--- ./results/domain.outTue Aug 20 01:32:57 2002
***
*** 143,154
( col1 ddef1
, col2 ddef2
, col3 ddef3
! , col4 ddef4
, col5 ddef1 NOT NULL DEFAULT NULL
, col6 ddef2 DEFAULT '88'
, col7 ddef4 DEFAULT 8000
, col8 ddef5
);
insert into defaulttest default values;
insert into defaulttest default values;
insert into defaulttest default values;
--- 143,155
( col1 ddef1
, col2 ddef2
, col3 ddef3
! , col4 ddef4 PRIMARY KEY
, col5 ddef1 NOT NULL DEFAULT NULL
, col6 ddef2 DEFAULT '88'
, col7 ddef4 DEFAULT 8000
, col8 ddef5
);
+ NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'defaulttest_pkey'
+for table 'defaulttest'
insert into defaulttest default values;
insert into defaulttest default values;
insert into defaulttest default values;
==
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Dann Corbit [EMAIL PROTECTED] writes: If you *know* of a buffer overrun, and simply decide not to fix it, that sounds very negligent to me. *sigh*, no one is doing that, and it is pure negligence on your part for replying to a thread that you clearly have not read. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
-Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 10:42 PM To: Dann Corbit Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane; Christopher Kings-Lynne; [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in Dann Corbit [EMAIL PROTECTED] writes: If you *know* of a buffer overrun, and simply decide not to fix it, that sounds very negligent to me. *sigh*, no one is doing that, and it is pure negligence on your part for replying to a thread that you clearly have not read. I read (in some other message) that this buffer overrun problem has been known for a very, very long time. To simply decide not to fix it means: It's on the todo list For generation after generation after generation. It does not mean that Someday, we hope to fix this. What I am saying is that there is nothing that could possibly be more important than fixing this, except some other known problem that could also cause billions of dollars worth of damage. Are there any such problems besides the buffer overrun problems? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Dann Corbit [EMAIL PROTECTED] writes: I read (in some other message) that this buffer overrun problem has been known for a very, very long time. No, the problem you're referring to (cash_out() and friends) is *not* a buffer overrun. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
-Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Monday, August 19, 2002 10:48 PM To: Dann Corbit Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane; Christopher Kings-Lynne; [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in Dann Corbit [EMAIL PROTECTED] writes: I read (in some other message) that this buffer overrun problem has been known for a very, very long time. No, the problem you're referring to (cash_out() and friends) is *not* a buffer overrun. I did miss the one message that said it was not a buffer overrun (I just got back from vacation, sorry). However, if it *can* crash the server, that sounds pretty important to me. Another message in this thread seemed to indicate that security was not a major focus (lagging behind adding new features). I do hope that is not true. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
To simply decide not to fix it means: snip What I am saying is that there is nothing that could possibly be more important than fixing this, except some other known problem that could also cause billions of dollars worth of damage. Are there any such problems besides the buffer overrun problems? This is an open source project. If you, or others with similar strong feelings about what is important to you, would like to submit patches in those areas I'm sure that they would be looked on favorably. To simply insist that everyone else have the same priorities on any topic is a bit unrealistic. However, I'd hope that if there are folks who look at this particular issue with your PoV they would speak up and think about helping out. If you didn't state a strong opinion on the topic then others might never catch on that there is a potential issue, let alone that they could contribute to a solution... - Thomas ---(end of broadcast)--- TIP 3: 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
