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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-general by date

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