| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: danger of stats_temp_directory = /dev/shm |
| Date: | 2013-04-25 16:14:13 |
| Message-ID: | 51795655.9060508@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/25/2013 11:24 AM, Peter Eisentraut wrote:
> On 4/25/13 12:09 AM, Tom Lane wrote:
>> I think we need it fixed to reject any stats_temp_directory that is not
>> postgres-owned with restrictive permissions. The problem here is not
>> with what it deletes, it's with the insanely insecure configuration.
> Yeah, the requirements should be similar to what initdb requires for
> PGDATA and pg_xlog.
>
>
Right.
I do think that best practice suggests using a dedicated ram drive
rather than /dev/shm. Here's an fstab entry I have used at one client's
site:
tmpfs /var/lib/pgsql/stats_tmp tmpfs
size=5G,uid=postgres,gid=postgres 0 0
I guess if we put in the sort of restrictions being suggested above I'd
add a mode argument to the mount options.
(This drive might seem large, but total RAM on this machine is 512Gb.)
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-04-25 16:24:12 | Re: minimizing the target list for foreign data wrappers |
| Previous Message | Alvaro Herrera | 2013-04-25 16:05:53 | Re: putting a bgworker to rest |