Re: pg_shmem_allocations view

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

On 2014-08-18 12:27:12 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
> >> 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.
>
> I agree that this has to be superuser-only if it's there at all.
>
> Should we consider putting it into an extension rather than having
> it in the core system? That would offer some additional protection
> for production systems, which really shouldn't have much need for
> this IMO.

I'd considered that somewhere upthread and decided that it'd require
exposing to much internals from shmem.c/dsm.c without a corresponding
benefit.

Greetings,

Andres Freund

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-08-18 16:33:37 Re: [PATCH] Incremental backup: add backup profile to base backup
Previous Message Tom Lane 2014-08-18 16:27:12 Re: pg_shmem_allocations view