Re: pg_shmem_allocations view

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_shmem_allocations view
Date: 2014-08-18 16:41:58
Message-ID: CA+TgmoZTmTbQe0t+YQUH9ZVvye8_2u2_aNj4pKwpJJ_idP63bQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-08-18 16:46:03 Re: pg_shmem_allocations view
Previous Message Tom Lane 2014-08-18 16:39:41 Re: pg_shmem_allocations view