Fix driver image path in drivers table

[iko1]

This PR fixes the issue in #7262

I fix the actual driver image path by using boost::filesystem::path::join to join between two paths.
The current code doesn't join correctly between two paths, because of that the driver path is partial.

before:

+---------------------+--------------------------------------------------------+---------+
| path                | name                                                   | source  |
+---------------------+--------------------------------------------------------+---------+
| C:\WINDOWS\system32 | PCI Express Root Port                                  | drivers |
| C:\WINDOWS\system32 | PCI Express Root Port                                  | drivers |
| C:\WINDOWS\system32 | Disk drive                                             | drivers |
| C:\WINDOWS\system32 | LSI Adapter, SAS 3000 series, 8-port with 1068         | drivers |
| C:\WINDOWS\system32 | PCI Express Root Port                                  | drivers |
| C:\WINDOWS\system32 | CD-ROM Drive                                           | drivers |
| C:\WINDOWS\system32 | Standard SATA AHCI Controller                          | drivers |
| C:\WINDOWS\system32 | USB Root Hub                                           | drivers |
| C:\WINDOWS\system32 | Standard Enhanced PCI to USB Host Controller           | drivers |

after:

[Smjert]

@iko1 Thanks for this PR.

While this makes the drivers table appear to work correctly, I think we should attempt to fix this at the core.

As far as I can see the problem is the registry table which is used via queryMultipleRegistryPaths, which is not filtering correctly the results it returns via the path constraint:

osquery> select count(key) from registry where path LIKE "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\%\ImagePath";
osquery planner: xBestIndex Evaluating constraints for table: registry [index=0 column=1 term=1 usable=1]
osquery planner: xBestIndex Evaluating constraints for table: registry [index=1 column=1 term=2 usable=1]
osquery planner: xBestIndex Evaluating constraints for table: registry [index=2 column=1 term=3 usable=1]
osquery planner: xBestIndex Adding index constraint for table: registry [column=path arg_index=1 op=65]
osquery planner: xBestIndex Recording constraint set for table: registry [cost=1.000000 size=1 idx=2]
osquery planner: xOpen Opening cursor (2) for table: registry
osquery planner: xFilter Filtering called for table: registry [constraint_count=1 argc=1 idx=2]
osquery planner: xFilter Adding constraint to cursor (2): path LIKE HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\%\ImagePath
osquery planner: Scanning rows for cursor (2)
osquery planner: xFilter registry generate returned row count:6792 <--------------- this should be the same as the count below
osquery planner: Closing cursor (2)
+------------+
| count(key) |
+------------+
| 642        |
+------------+

As you can see the table is generating 6792 rows and then sqlite is filtering them down to 642 when it finally processes the results, and the rows are only the ones with name = "ImagePath", because the path ends with ImagePath.

When using that function instead, sqlite is not involved (as it should be), but this means that there's nothing doing the final filtering.

I think we have two choices here:

1. Do not use the registry table to retrieve the registry keys (which is a good thing, in general we should extract APIs that could be used by all tables, but that do not use another table to do so, do not use a Row to store the data or involve sqlite for filtering).
   Then on a separate work, fix the registry table.

2. Fix the registry table filtering and move the decoupling work with separate APIs for later.

[Smjert]

I've filed a bug report for the registry table issue meanwhile, to keep it tracked: #7466

[iko1]

@Smjert, Thanks for the explanation. the query planer is super useful.
Due to you recommend to use API call instead of accessing another table(on this case Registry), I choose option (1) to make this PR valuable.

[iko1]

osquery> select image from drivers;
osquery planner: xBestIndex Recording constraint set for table: drivers [cost=1000000.000000 size=0 idx=1]
osquery planner: xOpen Opening cursor (1) for table: drivers
osquery planner: xFilter Filtering called for table: drivers [constraint_count=1 argc=0 idx=1]
osquery planner: Scanning rows for cursor (1)
osquery planner: xFilter drivers generate returned row count:211
osquery planner: Closing cursor (1)

I've changed the code to access directly Windows Registry instead of querying another table to retrieve the image path of a driver.

[Smjert]

Thanks for the changes!
This starts to look cleaner, this should be the last round of changes I think!

[Smjert]

I'll have a look at this in the weekend, sorry for the delay!

[Smjert]

Thanks @iko1 for moving this forward.
I've better tested this and found additional inconsistencies. After these are fixed we should be hopefully good to go!

EDIT: I also suggest to rebase this PR on latest master, otherwise the ReadTheDocs step will fail.

[iko1]

Thanks @iko1 for moving this forward. I've better tested this and found additional inconsistencies. After these are fixed we should be hopefully good to go!

EDIT: I also suggest to rebase this PR on latest master, otherwise the ReadTheDocs step will fail.

Thanks for your review. I've fixed the inconsistencies. I hope that this PR is good to go now.

[Smjert]

Thanks again for updating; final changes, then I'll approve since everything is working.