Since predicate name `import` is not allowed, I adopted `importNode` as it sort
of matches what `exprNode` does.
---
Due to only using `importMember` in `os_attr` we previously didn't handle
`import os.path as alias` :|
I did creat a hotfix for this (https://github.com/github/codeql/pull/4446), but
in doing so I realized the core of the problem: We're exposing ourselves to
making these kinds of mistakes by having BOTH importModule and importMember, and
we don't really gain anything from doing this!
We do loose the ability to easily only modeling `from mod import val` and not
`import mod.val`, but I don't think that will ever be relevant.
This change will also make us to recognize some invalid code, for example in
import os.system as runtime_error
we would now model that `runtime_error` is a reference to the `os.system`
function (although the actual import would result in a runtime error).
Overall these are tradeoffs I'm willing to make, as it does makes things simpler
from a QL modeling point of view, and THAT sounds nice 👍
This is not a very good test for showing that we don't handle direct imports,
but it was the best I had available without inventing something new. It's very
fragile, since any of these would propagate taint (due to handling all `join`
calls as if the qualifier was a string):
ospath_alias.join(ts)
ospath_alias.join(ts, "foo", "bar")
But this test DOES serve the purpose of illustrating that my fix works :D
Required a small change in `DataFlow::importModule` to get the desired
behaviour (cf. the type trackers defined in `moduleattr.ql`, but this
should be harmless. The node that is added doesn't have any flow
anywhere.
I'm not 100% sure whether this approach makes everything too magic, but I like
the fact that you can't _forget_ to make routed params remove-flow sources.
Overall idea is that `test/experimental/meta/ConceptsTest.qll` will set up
inline expectation tests for all the classes defined in `Concepts.qll`, so any
time you model a new instance of Concepts, you simply just import that
file. That makes the tests a little verbose, but allows us to share test-setup
between all the different frameworks we model.
Note that since the definitions of SystemCommandExecution subclasses are
scattered across multieple framework modeling qll files, it think it makes the
most sense to have the tests for each framework in one location.
I'm not 100% convinced about if this is the right choice or not (especially when
we want to write tests for sanitizers), but for now I'm going to try it out at
least.
