On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund <and...@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 <and...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to