On 5/2/16, Rolf Ade <rolf at pointsman.de> wrote: > > Richard Hipp <drh at sqlite.org> writes: >> A change summary for 3.13.0 is at >> https://www.sqlite.org/draft/releaselog/3_13_0.html > > Change the temporary directory search algorithm on Unix to allow > directories read and execute permission, but without read permission, > to > serve as temporary directories. > > .. "write and execute permission, but without read permission" ?
Yes. Apparently that is the new standard for security on unix systems. Write lets you create new temp files. Execute lets you check to see if a particular file exists. But because read is disabled, one cannot do an "ls" on the temporary directory to see what temp files other applications have created. Note that SQLite always unlinks its own temp files as soon as they are created, so you were never able to see SQLite's temp file, unless you are lucky and happen to read the directory during the microsecond in between the open() and unlink() system calls. But not all applications do that. The fact that SQLite formerly rejected temporary directories that omitted read permission was submitted to us as a security vulnerability. If that's the worst security vulnerability that SQLite ever creates, then I think we are doing a good job. Nevertheless, we have now fixed the issue. -- D. Richard Hipp drh at sqlite.org
