Re: [HACKERS] [0/4] Proposal of SE-PostgreSQL patches
On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer volume here, this is the patch to start
with, because it's got all the core changes to the server. I'm also in
the camp that would like to see this feature added, but rather than just
giving it a +1 I started looking at it.
The overall code is nice: easy to understand, structured modularly. I
have some concerns though. The first two things that jump out at me on an
initial review appear right from the beginning for those who want to take
a look:
-I'm a bit unnerved by both the performance and reliability implications
from how the security check calls are done in every case, even if there is
no SELinux support included. Those checks are sitting in some pretty low
level tuple and heap calls.
The approach taken here is to put all the #ifdef logic into the
underlying ACE interface (see patch [2/4]), so that the caller doesn't
have to care. If SELinux support is off then the calls turns into
void x(y) {} or
bool a(b) { return true; }
This is a very clean design, but it's putting extra (possibly optimized
away) calls into a lot of places. While it would be uglier, it might make
sense to put that on/off logic in all the places where the calls are made,
so that when you turn SELinux support off most of the code really does go
completely away rather than just turning into stubs.
-The only error reporting and handling method used is elog(ERROR,
That seems a bit heavy handed for something that can be expected to happen
all the time.
If I understand this correctly, when you're scanning a table with 1000
rows where you're only allowed to see 50% of them, that's going to be 500
call to elog(), one for each tuple you can't see. Having a tuple get
screened out isn't really an error per se, and while I can see how
sensitive installs would want those all reported there are others where
this volume of log activity would be too much. Just because someone with
classified clearance is looking at a big table that also has a lot of
secret info in it, not all installs will want a million errors reported
just because there's data that person can't see available.
At a minimum, this needs some finer log control, and maybe a rethinking
altogether of how to handle error cases.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [0/4] Proposal of SE-PostgreSQL patches
Greg Smith [EMAIL PROTECTED] writes:
The approach taken here is to put all the #ifdef logic into the underlying
ACE interface (see patch [2/4]), so that the caller doesn't have to care. If
SELinux support is off then the calls turns into
void x(y) {} or
bool a(b) { return true; }
This is a very clean design, but it's putting extra (possibly optimized away)
calls into a lot of places. While it would be uglier, it might make sense to
put that on/off logic in all the places where the calls are made, so that when
you turn SELinux support off most of the code really does go completely away
rather than just turning into stubs.
It's nicer to do it the way they have but we don't generally trust compilers
to inline functions. Is it hard to make those functions into macros?
-The only error reporting and handling method used is elog(ERROR, That
seems a bit heavy handed for something that can be expected to happen all the
time.
If I understand this correctly, when you're scanning a table with 1000 rows
where you're only allowed to see 50% of them, that's going to be 500 call to
elog(), one for each tuple you can't see. Having a tuple get screened out
isn't really an error per se, and while I can see how sensitive installs would
want those all reported there are others where this volume of log activity
would be too much. Just because someone with classified clearance is looking
at a big table that also has a lot of secret info in it, not all installs will
want a million errors reported just because there's data that person can't see
available.
I don't understand, if it's ERROR it would throw an error and stop the current
query. Or is this all within a PG_TRY() ?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
On Wed, Apr 30, 2008 at 05:33:38PM -0400, Tom Lane wrote: you're at risk of some clients being secure and some not. I thought what we were discussing was a server-side GUC parameter that would disallow more than one SQL statement per PQexec. That was certainly what I was intending, yes. The _principal_ trick with SQL injection is to fool the application into somehow handing a ; followed by an arbitrary SQL statement. There are of course other things one can do, but most of them are constrained to abuse of statements your application already performs. This injection problem, on the other hand, allows an attacker to do whatever they want. Obviously, if the server simply throws an error whenever one tries to do this, the attack will be foiled. It sounded to me like a patch that implemented this was already rejected. I agree that it's a bit filthy, and I'd way prefer that people build their applications such that these vectors aren't open in the first place. But given the prevalence of quick and dirty development with code one hasn't always completely vetted, this might be a nice feature in some environments. As long as it's possible to turn it off (we'd probably need to make it require a server restart to make it really effective), I think it could be useful. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Odd timezone backend output
I am confused about the below results. The backend is in EDT but it is converting timestamps into EST ... excluding NOW(). Regardless of the timezone provided, the backend is dishing out EST. [EMAIL PROTECTED] ~]# uname -a 2.6.9-67.0.4.EL #1 Sun Feb 3 06:53:29 EST 2008 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] ~]# date Thu May 1 09:54:17 EDT 2008 postgres=# select version(); PostgreSQL 8.3devel on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8) postgres=# set datestyle='Postgres, MDY'; postgres=# select now(); now - Thu May 01 09:28:53.164084 2008 EDT postgres=# select '1997-01-29 12:31:42.92214 EDT'::timestamptz; timestamptz Wed Jan 29 11:31:42.92214 1997 EST postgres=# select '1997-01-29 12:31:42.92214 PST'::timestamptz; timestamptz Wed Jan 29 15:31:42.92214 1997 EST Is this expected behavior? I am not sure if I am missing something or my results are wrong. Is there a setting that needs tweaking? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Odd timezone backend output
Andrew Chernow [EMAIL PROTECTED] writes: I am confused about the below results. The backend is in EDT but it is converting timestamps into EST ... excluding NOW(). Regardless of the timezone provided, the backend is dishing out EST. Try a date that's actually during the EDT part of the year. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Odd timezone backend output
On Thu, May 01, 2008 at 09:53:41AM -0400, Andrew Chernow wrote: I am confused about the below results. The backend is in EDT but it is converting timestamps into EST ... excluding NOW(). Regardless of the timezone provided, the backend is dishing out EST. First, this doesn't really belong on hackers, which is for hacking of the back end. If you're going to follow up, please take it to -general or something. Your client thinks it's in America/Toronto or something similar. You can set the time zone you're in by SET TIME ZONE (or timezone). There's a lot more about this in the manual at http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html#DATATYPE-TIMEZONES postgres=# select now(); now - Thu May 01 09:28:53.164084 2008 EDT May is in Daylight time in (AFAIK all) Eastern zones. postgres=# select '1997-01-29 12:31:42.92214 EDT'::timestamptz; timestamptz Wed Jan 29 11:31:42.92214 1997 EST postgres=# select '1997-01-29 12:31:42.92214 PST'::timestamptz; timestamptz Wed Jan 29 15:31:42.92214 1997 EST January is in Standard time in Eastern zones. Note that you asked for 1997-01-29 12:31:42.92214 EDT, and got back what time that would be _for your actual timezone_. Same thing for the Pacific case. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Odd timezone backend output
Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: I am confused about the below results. The backend is in EDT but it is converting timestamps into EST ... excluding NOW(). Regardless of the timezone provided, the backend is dishing out EST. Try a date that's actually during the EDT part of the year. regards, tom lane Different systems do different things with Daylight time. For instance: NTFS adjusts winter file times while in daylight savings (A file time of Jan 20 6PM reads Jan 20 7PM while in Daylight Time). Whether that is good or bad is a different story. I don't really have a problem with either, just needed a little clarity. Thanks, -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
Andrew Sullivan [EMAIL PROTECTED] writes: The _principal_ trick with SQL injection is to fool the application into somehow handing a ; followed by an arbitrary SQL statement. There are of course other things one can do, but most of them are constrained to abuse of statements your application already performs. This injection problem, on the other hand, allows an attacker to do whatever they want. They're the principal trick only because they're the most convenient. If you block them (as you can today by using PQExecParams() !!!) then people will switch to other things. c.f. http://www.areino.com/hackeando/ (there is a semicolon here but that's a microsoft-ism, postgres would actually be more affected by this style of attack without the semicolon) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Odd timezone backend output
Andrew Chernow wrote: Tom Lane wrote: Andrew Chernow [EMAIL PROTECTED] writes: I am confused about the below results. The backend is in EDT but it is converting timestamps into EST ... excluding NOW(). Regardless of the timezone provided, the backend is dishing out EST. Try a date that's actually during the EDT part of the year. regards, tom lane Different systems do different things with Daylight time. For instance: NTFS adjusts winter file times while in daylight savings (A file time of Jan 20 6PM reads Jan 20 7PM while in Daylight Time). Whether that is good or bad is a different story. I don't really have a problem with either, just needed a little clarity. The only file times we should ever be interested in are surely epoch times, which should be unaffected by time zones. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
Gregory Stark [EMAIL PROTECTED] writes: Andrew Sullivan [EMAIL PROTECTED] writes: The _principal_ trick with SQL injection is to fool the application into somehow handing a ; followed by an arbitrary SQL statement. They're the principal trick only because they're the most convenient. If you block them (as you can today by using PQExecParams() !!!) then people will switch to other things. Sure, modifying the WHERE clause is still possible, but the attacker is a lot more limited in what he can do if he can't tack on a whole new command. The important aspects of this that I see are: 1. Inexpensive to implement; 2. Unlikely to break most applications; 3. Closes off a fairly large class of injection attacks. The cost/benefit ratio looks pretty good (unlike the idea that started this thread...) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
On Thu, May 01, 2008 at 11:26:21AM -0400, Tom Lane wrote: 1. Inexpensive to implement; 2. Unlikely to break most applications; 3. Closes off a fairly large class of injection attacks. The cost/benefit ratio looks pretty good (unlike the idea that started this thread...) That's a much more elegant way of putting what I thought. Thanks, Tom. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Internal design of MERGE, with Rules
On Thu, 2008-05-01 at 00:26 +0100, Sam Mason wrote: On Wed, Apr 30, 2008 at 04:58:52PM +0100, Simon Riggs wrote: That means we probably need to introduce new infrastructure in the tcop or executor modules to handle queries-within-queries. This isn't special-casing MERGE so much as introducing infrastructure for a new class of query, such as MERGE, REPLACE, INSERT ELSE UPDATE. (Merge itself does cover almost all cases of this type of query, but we'd be able to fairly easily support all of the different syntax). MERGE would then be represented by a query that has many side queries (so called so we don't confused calling them sub-queries). Why make them special cases? (I'm sure there's a good reason!) Well, I'm not making them special cases. The infrastructure would be generalised for any statement type that wanted to do roughly this. I've sometimes wanted to be able to put DML statements inside SELECT statements. The following is a slightly reasonable example: INSERT INTO ilog (i,ts,n) SELECT i, now(), COUNT(*) FROM ( INSERT INTO bar (x,y) SELECT 5, n FROM baz WHERE i = 10 RETURNING i) x GROUP BY i; OK, but that's not what I'm working on... useful as it sounds. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
Sure, modifying the WHERE clause is still possible, but the attacker is a lot more limited in what he can do if he can't tack on a whole new command. I hacked into a site like that some day to show a guy that you shouldn't trust magicquotes (especially when you switch hosting providers and it's not installed at your new provider, lol). Binary search on the password field by adding some stuff to the WHERE... You could still wipe out tables (just add a ' OR 1;-- to the id in the url to delete somthing... But it's true that preventing multi-statements adds a layer of idiot-proofness... a rather thin layer... The important aspects of this that I see are: 1. Inexpensive to implement; 2. Unlikely to break most applications; 3. Closes off a fairly large class of injection attacks. The cost/benefit ratio looks pretty good (unlike the idea that started this thread...) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Let the commit fest begin!
It's May 1st, which means it's time for our second 8.4 commit fest. I took a quick look through my inbox and added some pending patches to http://wiki.postgresql.org/wiki/CommitFest:May but it's entirely likely there are still some missing from the queue. Would authors of submitted patches please check that (a) your patch is in the queue, and (b) the most recent version is linked to? I've left the page labeled as accepting new contributions for the moment, but we should close it up as soon as any stragglers have been identified. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
Hi, disallow more than one SQL statement per PQexec. I agree, it would help. 1. Inexpensive to implement Disabling literals wouldn't be much harder to implement I believe, but I don't know the PostgreSQL internals. 2. Unlikely to break most applications; That's true. 3. Closes off a fairly large class of injection attacks. Unfortunately, it doesn't prevent SQL injection at all. Yes, updating and deleting data is harder (if the SQL injection is on a SELECT), but if an attacker only wants to destroy something he could use SETVAL. There is almost zero protection from reading data (no matter where the SQL injection is). It is quite simple to write an automated tool that downloads the whole database contents (first the catalog, and then all the data). Downloading the data would be a bit slower if the SQL injection is in the WHERE clause. Actually, it would be quite fun to write a generic tool ;-) Tools are usually used by the script kiddies. My website was once hacked by a 14 year old boy. He used a tool that read the admin password via SQL injection. Disabling literals is still the only way to actually protect from SQL injection. Except Meredith's libdejector, which is even a bit better as far as I see, but requires more work from the developer. I don't count Microsoft LINQ (or Java Quaere) currently because that would require a complete re-write of the application. Regards, Thomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [0/4] Proposal of SE-PostgreSQL patches
Greg Smith wrote:
On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer volume here, this is the patch to start
with, because it's got all the core changes to the server. I'm also in
the camp that would like to see this feature added, but rather than just
giving it a +1 I started looking at it.
The overall code is nice: easy to understand, structured modularly. I
have some concerns though. The first two things that jump out at me on
an initial review appear right from the beginning for those who want to
take a look:
Thanks for your attention reviewing.
-I'm a bit unnerved by both the performance and reliability implications
from how the security check calls are done in every case, even if there
is no SELinux support included. Those checks are sitting in some pretty
low level tuple and heap calls.
The approach taken here is to put all the #ifdef logic into the
underlying ACE interface (see patch [2/4]), so that the caller doesn't
have to care. If SELinux support is off then the calls turns into
void x(y) {} or
bool a(b) { return true; }
This is a very clean design, but it's putting extra (possibly optimized
away) calls into a lot of places. While it would be uglier, it might
make sense to put that on/off logic in all the places where the calls
are made, so that when you turn SELinux support off most of the code
really does go completely away rather than just turning into stubs.
Your concern is fair enough. I indeed used inline function to avoid unnecessary
invokation in the previous version, as follows:
http://code.google.com/p/sepgsql/source/browse/branches/pgsql-8.2.x/sepgsql/src/include/security/pgace.h
However, I changed this design, because it requires any security modules
have to provides its implementation for any hooks, including just a stub.
In the current design, author of another security modules can leave unused
hooks unchanged. It improves code maintenancability.
But an inspiration hit me just now.
If we declare any hooks as static inline functions which includes #ifdef
block, it can resolve these matters as follows:
EXAMPLE
static inline bool pgaceHeapTupleInsert(Relation rel, HeapTuple tuple,
bool is_internal, bool with_returning) {
#ifdef HAVE_SELINUX
if (sepgsqlIsEnabled())
return sepgsqlHeapTupleInsert(rel, tuple, is_internal, with_returning);
#endif
return true;
}
Is it reasonable idea?
-The only error reporting and handling method used is elog(ERROR,
That seems a bit heavy handed for something that can be expected to
happen all the time.
SE-PostgreSQL invokes elog(ERROR,..., when a given query tries to access
violated columns, tables and so on, but not for each tuple.
In row-level access controls, it filters violated tuples without aborting
query execution. However, elog(NOTICE,... can be invoked, if the security
policy requires to generate access denied logs on row-level.
If I understand this correctly, when you're scanning a table with 1000
rows where you're only allowed to see 50% of them, that's going to be
500 call to elog(), one for each tuple you can't see.
The security policy can control whether access denied logs should be
printed, or not.
In the default security policy provided by the patch [4/4], row-level
access denied logs are disabled to avoid flood of logs as you noticed.
If you want to turn on/off row-level logs, use the following command:
# setsebool -P sepgsql_enable_audittuple=(1|0)
It changes the internal state of security policy, and SE-PostgreSQL
works according to this one.
Having a tuple
get screened out isn't really an error per se, and while I can see how
sensitive installs would want those all reported there are others where
this volume of log activity would be too much. Just because someone
with classified clearance is looking at a big table that also has a lot
of secret info in it, not all installs will want a million errors
reported just because there's data that person can't see available.
At a minimum, this needs some finer log control, and maybe a rethinking
altogether of how to handle error cases.
Thanks,
--
KaiGai Kohei [EMAIL PROTECTED]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
Thomas Mueller wrote: Disabling literals is still the only way to actually protect from SQL injection. Except Meredith's libdejector, which is even a bit better as far as I see, but requires more work from the developer. I don't count Microsoft LINQ (or Java Quaere) currently because that would require a complete re-write of the application. I honestly don't think there's any chance of this happening, for the many good reasons previously covered in this debate. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
Thomas Mueller [EMAIL PROTECTED] writes: 1. Inexpensive to implement Disabling literals wouldn't be much harder to implement I believe, but I don't know the PostgreSQL internals. You're ignoring the client-side costs of repairing broken applications. (If it only broke applications that were in fact insecure, that would be one thing, but having to change code that there is nothing wrong with is not something that people will accept easily.) Disabling literals is still the only way to actually protect from SQL injection. If it were actually a complete defense then maybe the costs would be justifiable; but it isn't, as per previous discussion. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Protection from SQL injection
On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote: But it's true that preventing multi-statements adds a layer of idiot-proofness... a rather thin layer... As I already said in a previous remark in this thread, I don't really like partial security solutions. What the no multi-statement SQL switch adds is a complete protection against _one class_ of injection attacks. What is nice about it is that it completely eliminates that class of attacks, so they are no longer something one needs to worry about. They do not, of course, prevent every kind of injection attack. I think the thread has already had ample evidence that such complete prevention is either impractical to implement, too costly to existing applications, too limiting, not actually effective (i.e. not really complete prevention), or some combination of the above. That's not an argument that the simple change that is effective for only one class of attacks is a bad idea. Making the battlefield smaller is one thing one can do to decrease one's exposure to attack. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Regression test fails when BLCKSZ is 1kB
I wrote: Another possible answer is to change the minimum to be just 64K always. I'm not certain that it's really sensible to tie the minimum work_mem to BLCKSZ --- I don't think we do anything where work_mem is controlling a pool of page buffers, do we? I've committed this change in HEAD. There's no desire to back-patch it is there? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Odd timezone backend output
NTFS adjusts winter file times while in daylight savings The only file times we should ever be interested in are surely epoch times, which should be unaffected by time zones. cheers andrew epoch, or at least non-timezone adjusted times, is the way every modern FS stores file times, no one said otherwise. There is a big difference between time storage and display ... I was talking about display. Postgres deals with both so at some point, a file time (or any time) will get displayed. There are different ways of handling daylight display, I have yet to find a technically correct way of doing it. The more I think about it, I personally like the display behavior of NTFS file times over something like EXT3. When I am in EDT, it is useful to have all display times in that zone (regardless of whether that time falls within winter or summer) ... just as they would if I switched to PST. -- andrew chernow eSilo, LLC. --every bit counts -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] GDB X Postgresql 8 - Failed to read a valid object file image from memory
Hi! I tried to use GDB with postgresql 8 and I didnt have success. Can you help me? I tried like as I did in postgresql 7.4 I run configure like this: ./configure --prefix=/usr/local/pgsql8 --enable-debug --enable-cassert --enable-depend After, I run make, make install, initdb After this, I tried run gdb, but I dont enter in backend. See this: [EMAIL PROTECTED]:/home/anacrl$ gdb postgres GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-linux-gnu... (gdb) run Starting program: /usr/local/pgsql8/bin/postgres Failed to read a valid object file image from memory. LOG: database system was shut down at 2008-05-01 22:56:41 BRT LOG: database system is ready to accept connections LOG: autovacuum launcher started So, I think that have something wrong (Failed to read a valid object file image from memory). Can you help me? I tried run psql and attached process pid too, but no success. :-( Thanks, Ana Carolina
Re: [HACKERS] GDB X Postgresql 8 - Failed to read a valid object file image from memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, May 01, 2008 at 11:02:17PM -0300, Ana Carolina Brito de Almeida wrote: Hi! I tried to use GDB with postgresql 8 and I didnt have success. Can you help me? So, I think that have something wrong (Failed to read a valid object file [...] image from memory). Can you help me? I tried run psql and attached process pid too, but no success. :-( You didn't per chance stumble upon this: http://www.nabble.com/Failed-to-read-a-valid-object-file-image-from-memory-%28gdb_6_6-branch%2C--kernel-2.6.20-rc6%29-td8671963.html Happens on Linux 2.6.20-ish. HTH - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIGqvzBcgs9XrR2kYRAlkhAJ90/HM4KeigvYMQmQNvnQybp+wpawCfSzC7 pkOXPDEcIjOjCQAjDac+seY= =xwBy -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
