Skip site navigation (1) Skip section navigation (2)

Re: backend crash following load command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "PgSQL General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: backend crash following load command
Date: 2006-11-28 21:09:11
Message-ID: 6360.1164748151@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
"Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
> also, if what Martijn is saying is correct, wouldn't that make the
> LOAD command unsupportably dangerous?

If you have write access to a file that you can LOAD, then you can
already put garbage into the backend's memory space, so I don't see
this as a security hole.  It'd be unfortunate if true though.

The mmap man page is pretty vague on the subject, but I wonder whether
the shlib isn't effectively treated as copy-on-write --- that is, any
attempted overwrite of the file happens only after the mmap region has
been fully copied.  Without that, it'd be impossible to update core
shared libraries like libc.so without a system reboot, but Linux doesn't
seem to need that.

I suspect that this issue is specific to dlsym() and has nothing to do
with the safeness of ordinary usage of a shared library.  The reason
8.2 is getting bit is that it tries to do a dlsym() lookup during shlib
unload, which we never did before.  (Merlin, I assume you have been
doing the same things with 8.1 and before without a problem?)

Hmm ... would it be worth doing the lookup of _PG_fini during library
load instead of unload, and saving the result?  This'd be a waste of
cycles if the library were never unloaded, which is much the normal
case, but library load probably isn't a critical path anyway.

			regards, tom lane

In response to

Responses

pgsql-general by date

Next:From: Tom LaneDate: 2006-11-28 21:22:22
Subject: Re: slow inet within cidr query
Previous:From: Oisin GlynnDate: 2006-11-28 21:06:48
Subject: Re: using a sequence as the functional equivalent to Oracle

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group