Preston Moore <prestonkmo...@gmail.com> added the comment:

I like Victor's idea for updating public functions to support file descriptors. 
 I could submit a patch for this instead if desired.

In the meantime, I've updated the pull request for this issue so the patch I 
originally created that compares inode numbers applies to 3.8.  I've included a 
test case as well.

I think Victor's idea may be superior to the inode comparison. It is in the 
same spirit as glibc preferring openat() rather than open() 
(https://lwn.net/Articles/738694/) to counter directories
changing during an operation.  

Alternatively, coreutils 
(https://github.com/coreutils/coreutils/blob/439741053256618eb651e6d43919df29625b8714/src/copy.c#L1051)
deals with this issue using inode comparison.  Perhaps this is because they 
don't have a clean way of supporting both paths and fds like we do with Python.

This overall issue has extra cause for concern because it can be exploited by 
an attacker as a security vulnerability 
(https://wiki.sei.cmu.edu/confluence/display/c/FIO45-C.+Avoid+TOCTOU+race+conditions+while+accessing+files).
  Additionally, Python projects have encountered similar bugs when 
re-implementing file operations themselves 
(https://code.djangoproject.com/ticket/8479)

I would be happy to fix this bug in any other spots identified using whichever 
strategy is preferred.  If it is possible to get functions operating on file 
descriptors without breaking public functions I think that is the strategy we 
should prefer.   If that is not possible, the above inode comparison strategy 
provides improvement if not a complete fix.
 
Should I submit additional bug reports for these other cases or should I just 
follow on here?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30400>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to