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
Shore Up File System Interactions to Avoid Unexpected Outcomes #1144
Shore Up File System Interactions to Avoid Unexpected Outcomes #1144
Conversation
Thanks for getting ahead of this one. Based on the original report, I figured the fix would be something like this. |
Another approach here is to catch If |
There are already several places we're checking for Basically, if we're trying to interact with a file or directory and it fails with an exception based on Additionally, we should probably ensure this policy applies to any interaction with "non-well-known" filesystem structures...or at least anywhere a user could reasonably have made their own changes. So, once a well-known tool is validated (like Xcode, java, android sdk, etc), we shouldn't need to worry about this....but trying to run |
8ed61dd
to
59f57e7
Compare
- When using user input to drive `subprocess` calls, the exception catching now includes `OSError` to account for unexpected aspects of the executables being run. - For instance, if the filepath in `JAVA_HOME` is not exlusively made up of directories, then `subprocess` will raise `NotADirectoryError`. If `JAVA_HOME` points to a binary itself such as`/usr/lib/jvm/bin/java`, then the check for `javac`, i.e. `subprocess.check_output(['/usr/lib/jvm/bin/java/bin/javac', '-version'])` raises `NotADirectoryError` since `java` is not a directory. - Additionally, checks for existence in the filesystem that require the path to be either a file or a directory, now check specifically for that characteristic.
59f57e7
to
a9f9d2a
Compare
NotADirectoryError
from invalid settings such as in JAVA_HOME
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not much to fault here - this is a pretty comprehensive audit.
I'm sure we could write a bunch more tests to individually confirm that "file is directory" type failures do indeed fail; and there's probably some really subtle masking condition where a weird permission error will be surfaced as a "does not exist". However, it's enough of an edge case that I'm not too concerned - if we ever get a user report of something like that happening, we can deal with it then.
Changes
subprocess
with user-input derived filepaths to executables now catchOSError
in case those executables have unepxected aspects that causessubprocess
to raise variations ofOSError
.JAVA_HOME
is not exlusively made up of directories, thensubprocess
will raiseNotADirectoryError
. For instance, ifJAVA_HOME
points to a binary itself such as/usr/lib/jvm/bin/java
, then the check forjavac
, i.e.subprocess.check_output(['/usr/lib/jvm/bin/java/bin/javac', '-version'])
raisesNotADirectoryError
sincejava
is not a directory.I was not previously aware of this behavior from
subprocess
. It seems to stem from the fact that the state returned from forking the child is anOSError
number0x14
.....instead ofOSError
number0x2
forFileNotFoundError
, for instance.This is simple to replicate, though:
TODO:
subprocess
with potentially problematic exe filepaths.Reference:
PR Checklist: