Before we can say if something is "secure" or not, we need a threat model -- i.e we need to agree which use cases we are protecting and from
what threats.
So far, I've seen these use cases:
1. File for the current process' private use
2. File/file name generated by the current process; written by another process,
read by current one
3. File name generated by the current process; written by the current process,
read by another one
And the following threats, three axes:
a. Processes run as other users
b. Processes run as the same user (or a user that otherwise automatically has
access to all your files)
1. Accidental collision from a process that uses CREATE_NEW or equivalent
2. Accidental collision from a process that doesn't use CREATE_NEW or equivalent
3. Malicious code creating files at random
4. Malicious code actively monitoring file creation
-1. read
-2. write
E.g. for threat b-4), it's not safe to use named files for IPC at all, only
case 1 can be secured (with exclusive open).
On 19.03.2019 16:03, Stéphane Wirtel wrote:
Hi,
Context: raise a warning or remove tempfile.mktemp()
BPO: https://bugs.python.org/issue36309
Since 2.3, this function is deprecated in the documentation, just in the
documentation. In the code, there is a commented RuntimeWarning.
Commented by Guido in 2002, because the warning was too annoying (and I
understand ;-)).
So, in this BPO, we start to discuss about the future of this function
and Serhiy proposed to discuss on the Python-dev mailing list.
Question: Should we drop it or add a (Pending)DeprecationWarning?
Suggestion and timeline:
3.8, we raise a PendingDeprecationWarning
* update the code
* update the documentation
* update the tests
(check a PendingDeprecationWarning if sys.version_info == 3.8)
3.9, we change PendingDeprecationWarning to DeprecationWarning
(check DeprecationWarning if sys.version_info == 3.9)
3.9+, we drop tempfile.mktemp()
What do you suggest?
Have a nice day and thank you for your feedback.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru
--
Regards,
Ivan
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
