This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rbcollins
Recipients Tom Hale, a.badger, rbcollins, serhiy.storchaka
Date 2019-06-04.00:13:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559607206.76.0.526045612485.issue36656@roundup.psfhosted.org>
In-reply-to
Content
I'd like to add a few notes; please do consider Windows interactions here - Windows does not have the same model for inode replacement that Posix has.

Secondly, I note that the thread model discussed here hasn't been particular well articulated. In particular the vagaries of directories with the sticky bit set are quite different to those where attacker and victim share group permissions : TOCTTOU attacks do imply that post-atomic operation attacks will be possible, and I disagree with the analysis by Serhiy suggesting that they are necessarily so.

However I also agree with Toshio that the os module is not the right place to provide a more secure API: we have to have the basic primitive exposed to Python code somewhere, otherwise the higher level APIs such as you'd like to use are not creatable.

My suggestion is that you put a module up on PyPI that provides the secure behaviour necessary, get some feedback on that, get some cross-platform experience, and then, if desired, propose it for inclusion in shutil or similar in the stdlib.

I'm also going to retitle this - because actually, os.link and os.symlink aren't racy *per se* on Posix - its how they are used that is racy: and the very fact that a secure variant can be written (however ugly) is demonstration of that.
History
Date User Action Args
2019-06-04 00:13:26rbcollinssetrecipients: + rbcollins, a.badger, serhiy.storchaka, Tom Hale
2019-06-04 00:13:26rbcollinssetmessageid: <1559607206.76.0.526045612485.issue36656@roundup.psfhosted.org>
2019-06-04 00:13:26rbcollinslinkissue36656 messages
2019-06-04 00:13:26rbcollinscreate