Re: danger of stats_temp_directory = /dev/shm - Mailing list pgsql-hackers

From Tom Lane
Subject Re: danger of stats_temp_directory = /dev/shm
Date
Msg-id 19282.1376531072@sss.pgh.pa.us
Whole thread Raw
In response to Re: danger of stats_temp_directory = /dev/shm  (Josh Berkus <josh@agliodbs.com>)
Responses Re: danger of stats_temp_directory = /dev/shm  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: danger of stats_temp_directory = /dev/shm  (Magnus Hagander <magnus@hagander.net>)
Re: danger of stats_temp_directory = /dev/shm  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> Before 9.3, it would delete one specific file from a potentially shared
>> directory.  In 9.3 it deletes the entire contents of a potentially shared
>> directory.  That is a massive expansion in the surface area for
>> unintentional deletion.  If we will disallow using shared directories
>> before the time 9.3 is released, that would fix it one way, but I don't
>> know if that is the plan or not.

> I can't see doing that.  I can see adding the requirement for 9.3, and
> then documenting it though.

I think we should change 9.3 to be restrictive about ownership/permissions
on the stats_temp_directory (ie, require owner = postgres user,
permissions = 0700, same as for the $PGDATA directory).  I agree that
back-patching such a change to the older branches is probably not a good
plan.  I can't quite parse what you say above, so I'm not sure if you're
fully agreeing with that position or not.

In addition to that, it might be a good idea to do what the comment in the
code suggests, namely do more than zero checking on each file name to try
to make sure it looks like a stats temp file name that we'd generate
before we delete it.  The ownership/permissions test wouldn't be enough
to prevent you from pointing at, say, ~postgres and thereby losing some
files you'd rather not.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: TODO request: multi-dimensional arrays in PL/pythonU
Next
From: Alvaro Herrera
Date:
Subject: Re: danger of stats_temp_directory = /dev/shm