Re: pg_shmem_allocations view - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_shmem_allocations view
Date
Msg-id CA+TgmoZTmTbQe0t+YQUH9ZVvye8_2u2_aNj4pKwpJJ_idP63bQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_shmem_allocations view  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pg_shmem_allocations view
Re: pg_shmem_allocations view
List pgsql-hackers
On Mon, Aug 18, 2014 at 12:00 PM, Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_shmem_allocations view
Next
From: Andres Freund
Date:
Subject: Re: pg_shmem_allocations view