Re: danger of stats_temp_directory = /dev/shm

<p dir="ltr"><br /> On Aug 15, 2013 3:44 AM, "Tom Lane" <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > Josh Berkus <<a
href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>>writes:<br /> > >> Before 9.3, it would delete one
specificfile from a potentially shared<br /> > >> directory.  In 9.3 it deletes the entire contents of a
potentiallyshared<br /> > >> directory.  That is a massive expansion in the surface area for<br /> >
>>unintentional deletion.  If we will disallow using shared directories<br /> > >> before the time 9.3
isreleased, that would fix it one way, but I don't<br /> > >> know if that is the plan or not.<br /> ><br
/>> > I can't see doing that.  I can see adding the requirement for 9.3, and<br /> > > then documenting it
though.<br/> ><br /> > I think we should change 9.3 to be restrictive about ownership/permissions<br /> > on
thestats_temp_directory (ie, require owner = postgres user,<br /> > permissions = 0700, same as for the $PGDATA
directory). I agree that<br /> > back-patching such a change to the older branches is probably not a good<p
dir="ltr">+1<pdir="ltr">><br /> > In addition to that, it might be a good idea to do what the comment in the<br
/>> code suggests, namely do more than zero checking on each file name to try<br /> > to make sure it looks like
astats temp file name that we'd generate<br /> > before we delete it.  The ownership/permissions test wouldn't be
enough<br/> > to prevent you from pointing at, say, ~postgres and thereby losing some<br /> > files you'd rather
not.<pdir="ltr">+1 on that as well. It shouldn't be that hard to do. <p dir="ltr">/Magnus