Re: pg_shmem_allocations view - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_shmem_allocations view
Date
Msg-id CA+TgmoY+zPmbbyToJfgsqq8P9r=qBC7zsnzvXL355e5KkEJcZg@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
List pgsql-hackers
On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
>> Hi
>> On Thu, May 8, 2014 at 4:28 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > Ok. A new version of the patches implementing that are
>> > attached. Including a couple of small fixups and docs. The latter aren't
>> > extensive, but that doesn't seem to be warranted anyway.
>>
>> Is it really actually useful to expose the segment off(set) to users?
>> Seems to me like unnecessary internal details leaking out.
>
> Yes. This is clearly developer oriented and I'd more than once wished I
> could see where some stray pointer is pointing to... That's not really
> possible without something like this.

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.

I fully agree with the idea of exposing the amount of free memory in
the shared memory segment (as discussed in other emails); that's
critical information.  But I think exposing address space layout
information is of much less general utility and, really, far too
risky.

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: wrapping in extended mode doesn't work well with default pager
Next
From: Andres Freund
Date:
Subject: Re: pg_shmem_allocations view