Robert Collins <robe...@robertcollins.net> added the comment:
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. ---------- nosy: +rbcollins title: Race conditions due to os.link and os.symlink POSIX specification -> Please add race-free os.link and os.symlink wrapper / helper _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36656> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
