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: (view raw or whole 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 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


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-2015 The PostgreSQL Global Development Group