Hi folks, a quick question around the following `f...
# general
l
Hi folks, a quick question around the following
file
query:
Copy code
SELECT * FROM file WHERE file.path LIKE '/usr/local/Caskroom/jd-gui/%%' AND file.path LIKE '/%.app';
It seems the first
LIKE
does the directory walk, and the second
LIKE
performs string matching? (I thought osquery would combine the two `LIKE`s somehow and then do the directory walk) Am not saying this is a bug, just checking if I'm understanding the behavior of the table.
f
those arguments may be colliding, you can run osqi with the
--planner
argument to possibly gain some insight, i would personally change that last clause to match on file.filename not file.path, maybe that will work for you?
also in your example, I think you have the '/" in the wrong place, it should be at the end :
Copy code
SELECT * FROM file WHERE file.path LIKE '/Applications/%' AND file.path LIKE "%.app/" LIMIT 5;
l
Hi @FG Thanks! Will try the
--planner
The thing is that they query works and I'm trying to understand why 🙂. Maybe I got it wrong that whenever you use
LIKE
on path it would do directory traversal, but seems that only one is being used for traversing (AFAICS).
Hey, I found out what's going on with this query: https://github.com/fleetdm/fleet/pull/24593#discussion_r1895747640 TL;DR: Basically
LIKE
is used first by osquery code to generate the paths AND then by the sqlite engine which will do string matching as usual. The second LIKE doesn't generate any results/paths (no
.apps
in
/
) but then it's useful for filtering just
.app
s returned by the first
LIKE
that does recursive search.
f
That makes sense thanks for the link.