Re: pg_shmem_allocations view

On 2014-08-18 12:41:58 -0400, Robert Haas wrote:
> On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> Unfortunately, that information also has some security implications.
> >> I'm sure someone trying to exploit any future stack-overrun
> >> vulnerability will be very happy to have more rather than less
> >> information about the layout of the process address space.
> >>
> >
> > Meh. For one it's just the offsets, not the actual addresses. It's also
> > something you can relatively easily compute at home by looking at a
> > couple of settings everyone can see. For another, I'd be perfectly
> > content making this superuser only. And if somebody can execute queries
> > as superuser, address layout information really isn't needed anymore to
> > execute arbitrary code.
>
> I'm just not sure it should be in there at all.

You realize that you can pretty much recompute the offsets from the
sizes of the individual allocations anyway? Yes, you need to add some
rounding, but that's about it. We could randomize the returned elements,
but that'd be rather annoying because it'd loose information.

> If we punt this off
> into an extension, it won't be available in a lot of situations where
> it's really needed. But although the basic functionality would have
> been quite useful to me on any number of occasions, I can't recall a
> single occasion upon which I would have cared about the offset at all.
> I wouldn't mind having a MemoryContextStats()-type function that could
> be used to print this information out by attaching to the backend with
> gdb, but the utility of exposing it at the SQL level seems very
> marginal to me.

I'd use for it in the past when trying to figure out what some pointer
pointed to. It's easy enough to figure out that it's in the main shared
memory segment, but after that it get's rather hard. And even if you
don't count that, it gives a sensible order to the returned rows from
the SRF.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services