Re: pg_shmem_allocations view
От | Andres Freund |
---|---|
Тема | Re: pg_shmem_allocations view |
Дата | |
Msg-id | 20140818163023.GA23679@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_shmem_allocations view (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_shmem_allocations view
|
Список | pgsql-hackers |
On 2014-08-18 12:27:12 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.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
В списке pgsql-hackers по дате отправления: