Osquery uses basic SQL commands to leverage a relational data-model to describe a device.

osquery

Hey there :wave:

I think I may be bumping into <https://github.com/osquery/osquery/issues/3212|this FIM issue> on Linux. The <https://osquery.readthedocs.io/en/stable/deployment/file-integrity-monitoring/#known-issues|known issues> section of the documentation says that this may occur on “some platforms”, but the issue itself mentions the author doesn’t have this issue on Linux. However, given the issue is 5 years old I wondered whether this may have changed.

As a concrete example, if I setup a watch on `/opt/path/%%`, start osquery, and then *create* `/opt/path/` as well as a new file under this path (`/opt/path/example.test`), these events don’t appear to ever be recorded by osquery. The same applies if I use the full-path to a file (`/opt/path/example.test`) in the osquery configuration, but which doesn’t exist when osquery starts.

I’m running OSQuery 5.9.1 using a 6.2.0 Kernel. Is this a known quirk, or is there something I’m doing wrong here? :slightly_smiling_face:

I should note that if this `/opt/path/` parent path exists at the time osquery starts, then the rule works without issue.

That's our experience also. Events only seem to be captured for paths that exist when osqueryd is started.

Okay, so it isn’t just me! Thanks for the note :sweat_smile:

Hi folks! Which event table are you querying?

(I'm working on some changes to fix this kind of issue for `process_file_events` in particular.)

Currently, using `SELECT * FROM file_events`

Yeah, you may know that `process_file_events` is the table I was interested in. :slightly_smiling_face:

&gt;  Currently, using `SELECT * FROM file_events` (edited)
Ah gotcha.

Is there a Github issue, or pull-request for the associated quirk with `process_file_events`? :smile:

Ah I think I found it! <https://github.com/osquery/osquery/issues/8062>