Skip to content

JS: track shell:true more in js/shell-command-constructed-from-input #11858

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

Merged
merged 3 commits into from
Jan 16, 2023

Conversation

erik-krogh
Copy link
Contributor

@erik-krogh erik-krogh commented Jan 10, 2023

@github-actions github-actions bot added the JS label Jan 10, 2023
@erik-krogh erik-krogh marked this pull request as ready for review January 10, 2023 14:27
@erik-krogh erik-krogh requested a review from a team as a code owner January 10, 2023 14:27
@erik-krogh erik-krogh added the no-change-note-required This PR does not need a change note label Jan 10, 2023
Copy link
Contributor

@yoff yoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some questions. Specifically, I would like to establish if api graphs in js has a reason to deviate form the rest or if there is a bug in all of them..

exists(API::Node node |
node.asSink() = sys.getOptionsArg() and
node.getMember("shell").getAValueReachingSink().mayHaveBooleanValue(true)
)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the old bit not covered by the new bit (so that we could have only the new bit)?
Do you happen to have a concrete piece of code that is matched by the old and not the new?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not guarantee that all SystemCommandExecution have a corresponding API::Node.
I think there are API::Node for all of them right now, but if we model more SystemCommandExecution they might not all have API::Nodes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I can accept that. I might add a comment before line 162 saying something like "In case sys.getOptionsArg is not a sink for any API node".

Comment on lines 213 to 218
DataFlow::Node getAValueReachingSink() {
result = Impl::trackDefNode(this.asSink())
or
// in case `asSink()` is not a `SourceNode`.
result = this.asSink()
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If asSink() is not a SourceNode, you should simply get a local source for it, is that not good enough? I could se it failing, if rhs(_, _, asSink()) does not hold at all, but then that predicate should perhaps be extended? What is the concrete value that prompted this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If asSink() is not a SourceNode, you should simply get a local source for it

The problem is that .getALocalSource() has no result.
A boolean literal is not a SourceNode, and .getALocalSource() has no result.
I think SourceNode in Python is a bit different. I suspect that you are guaranteed that .getALocalSource() has a result?


The motivation was a boolean literal being written to a property.


Now that I think about it: getAValueReachingSink adds nothing when we are tracking booleans, I would need a small-step type-backtracker (because that doesn't depend on SourceNode).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, in Python there will always be a local source. If nothing else, then the node itself.

Copy link
Contributor

@yoff yoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@erik-krogh erik-krogh merged commit 8ccc384 into github:main Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
JS no-change-note-required This PR does not need a change note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants