Re: pg_shmem_allocations view - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_shmem_allocations view
Date
Msg-id 20140818160050.GC4030@awork2.anarazel.de
Whole thread Raw
In response to Re: pg_shmem_allocations view  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_shmem_allocations view
Re: pg_shmem_allocations view
List pgsql-hackers
On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> 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.

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.

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_shmem_allocations view
Next
From: Robert Haas
Date:
Subject: Re: Function to know last log write timestamp