-
Notifications
You must be signed in to change notification settings - Fork 4
Feature/tree sitter python subprocess syscalls #195
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
base: main
Are you sure you want to change the base?
Changes from all commits
0e9aa28
f398d50
12110cd
6d8dceb
8cb6a82
95df097
598c489
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| import os | ||
| import subprocess | ||
| import subprocess as sp | ||
| from subprocess import run as sproot_run | ||
|
|
||
|
|
||
| def positives(): | ||
| # Should match: "os.system" | ||
| os.system("ls -l /tmp") | ||
|
|
||
| # Should match: "os.system" | ||
| os.system("echo from os.system") | ||
|
|
||
| # Should match: "subprocess.run" | ||
| subprocess.run(["echo", "from subprocess.run"]) | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. issue: It looks like test case is giving us an extraneous result: When the argument to subprocess.run is a list, only the first item in the list will have the command to run in it (every item in the list afterwards is just an argument). When the argument to subprocess.run is a string, I think it behaves the same as os.system (in most cases). The underlying cause seems to be that right now is that when it is a list we seem to be treating each item in the list as if it were a command. suggestion: Some other commands that can be treated the same way as subprocess.run for spawning a subprocess are: |
||
|
|
||
|
|
||
| # Depending on your resolver, these MAY or MAY NOT match | ||
| # (aliases/from-imports). Keep them if you want extra coverage. | ||
| sp.run("echo from sp.run", shell=True) # alias of subprocess | ||
| sproot_run(["echo", "from from-import"]) # from-import alias | ||
|
|
||
| def negatives(): | ||
| # Should NOT match (not in the allowlist) | ||
| subprocess.check_call(["echo", "should NOT match"]) | ||
| os.path.join("a", "b") # not a syscall | ||
| run("rm -rf /tmp/somewhere") | ||
|
|
||
| if __name__ == "__main__": | ||
| positives() | ||
| negatives() | ||
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.
Question for all: Do we want only matches that exist in the databases?
Uh oh!
There was an error while loading. Please reload this page.
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.
I wound tend to think we'd want all the matches, even if they don't exist in the database.
In some case that might even be more interesting: "What's this call to this random program I haven't heard of <xyz>"
The C++ parser (for #include statements, not sys calls) does include results that it doesn't find in the database, they just result in an entry with an empty list for "no matches found" eg. ("example_included_file.h", [])
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.
Ok, great point. I will make that change!