Author vstinner
Recipients neologix, vstinner
Date 2014-05-16.09:17:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
In-reply-to
Content
Linux 3.11 introduced a new file flag "O_TMPFILE". The flag is exposed in Python, see the issue #18673.

"O_TMPFILE is a new open(2)/openat(2) flag that makes easier the creation of secure temporary files. Files opened with the O_TMPFILE flag are created but they are not visible in the filesystem. And as soon as they are closed, they get deleted - just as a file you would have opened and unlinked."
http://kernelnewbies.org/Linux_3.11#head-8be09d59438b31c2a724547838f234cb33c40357

Does it make sense to use this flag in tempfile.TemporaryFile?

Attached patch is a work-in-progress patch for tempfile.

> if hasattr(_os, 'O_TMPFILE'):
>     _O_TMPFILE = _os.O_TMPFILE
> elif _sys.platform == 'linux':
>     __O_TMPFILE = 0o20000000
>     _O_TMPFILE = (__O_TMPFILE | _os.O_DIRECTORY)

The second if should be removed. I used it because my Linux kernel (3.14) supports the flag, but the constant is not defined yet in C headers of my C library (glibc 2.18).

> flags = (flags | _O_TMPFILE) & ~_os.O_CREAT

O_CREAT is incompatible with O_TMPFILE.

Bonus point of the flag: no need to compute a random name! Just pass the temporary directory.

To do: test the patch on Linux < 3.11 to see how the flag is interpreted. If the flag is ignored, we open the directory in write mode! That's insafe. If the flag raises an error, we should fallback to the current implementation and remember that the flag is not supported.

I implemented something similar for O_CLOEXEC and SOCK_CLOEXEC flags (PEP 433).
History
Date User Action Args
2014-05-16 09:17:21vstinnersetrecipients: + vstinner, neologix
2014-05-16 09:17:21vstinnersetmessageid: <1400231841.29.0.337128735098.issue21515@psf.upfronthosting.co.za>
2014-05-16 09:17:21vstinnerlinkissue21515 messages
2014-05-16 09:17:20vstinnercreate