New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add failover for follow_symlinks and effective_ids where possible #59364
Comments
Serhiy Storchaka suggested (in private email, not on tracker or python-dev): why not make follow_symlinks and effective_ids failover where possible? Let's take the example of effective_ids first, that's simpler. Let's say the user calls Supporting this is easy: if effective_ids=True, and !defined(HAVE_FACCESSAT), but we have all four of the get{e|}{u|g}id() functions, do the above comparison and if it is just call access(). It's a bit more complicated with follow_symlinks. Let's say they call How do we detect that the file is a symbolic link? That's easy, call lstat(). On Windows, if they gave us a wide path, call win32_lstat_w(). If they passed in a non-default dir_fd, call fstatat() (if available). The one place where we can't fail over gracefully: os.stat() If we don't have the appropriate native stat function (lstat or fstatat), then obviously we can't stat nofollow the file to see if it's not a symbolic link and call normal stat(). Sad face. The attached patch implements all of the above. It passes the regression test suite on Linux 64-bit (with and without pydebug) and Windows 32-bit (Debug and Release). |
It also passes OS X. There are no patch specific tests though. And alas, I don't have any platform at hand that would benefit from these additions. :( The idea sounds good to me and the code LGTM though. However I can't really say much as I couldn't actually run it. |
I don't like this idea. Normally the system calls wrapped by the os module are fairly atomic. Here you're introducing the possibility for potentially nasty race conditions and exploits. |
I think you're right. As Antoine pointed out in irc, for POSIX platforms, modules in os are almost exclusively atomic. This is a useful (if undocumented) feature from a security viewpoint, and we should not break it lightly. Closing as wontfix. If someone thinks it's salvageable and wants to resurrect it, please discuss here. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: