search

osquery / osquery

SQL powered operating system instrumentation, monitoring, and analytics.
https://osquery.io
Other
21.53k stars 2.43k forks source link

Carve Request ID erroneously uses last distributed query #6727

Open zwass opened 3 years ago

zwass commented 3 years ago

Bug report

What operating system and version are you using?

Any

What version of osquery are you using?

4.5.1

What steps did you take to reproduce the issue?

Schedule a query that makes a file carve.

What did you expect to see?

Carve Request ID provided by osquery is the name of the scheduled query (or some other appropriate value).

What did you see instead?

Carve Request ID is the name of the most recent distributed query that osqueryd executed (even though that query is no longer executing, and even if that query did not even use the carves table).

theopolis commented 3 years ago

I definitely caused this bug but I am unsure of a good way to fix it. Any help would be greatly appreciated.

hughneale commented 3 years ago

Ah, I was just about to report this. Really easy to replicate if you're using scheduled carves. I think its due to this line: #3252. However, I'm going to investigate further.

directionless commented 3 years ago

Is this still present after #6671 ?

theopolis commented 3 years ago

This is still present and I'm working on a stop-gap solution that reduces the confusion.

apinter-figma commented 1 year ago

@theopolis kind of an old issue here, but just to double check my understanding from the code and this issue. The code now generates a distinct uuid for each call to genCarves, but it is not the uuid of the initiating distributed query (or scheduled query). This issue to close would mean that the appropriate spawning distributed query uuid got attached as the request id to each individual carve.