Title
#windows
y

Yves Dolce

01/23/2020, 11:55 PM
Switching topic. Developing an extension (not a plugin). The online doc doesn't seem to be up to date. Using the latest osquery repo,
sdk.h
is under
osquery\osquery\sdk
but
events.h
is under
osquery\osquery\include\osquery
. There's no
dispatcher.h
header file but a
osquery\osquery\dispatcher
folder. Same for
database.h
, just database folders. Yet I look around at existing extensions and I see:
#include <osquery/database.h>
#include <osquery/dispatcher.h>
#include <osquery/events.h>
#include <osquery/sdk.h>
Do I need to successfully build osquery to start developing extensions?
a

alessandrogario

01/24/2020, 1:47 PM
Yes, you need to build the extensions at the same time as osquery. There are some examples here: https://github.com/osquery/osquery/tree/master/osquery/examples The extension code has to be copied/symlinked inside the external folder: https://github.com/osquery/osquery/blob/master/external/CMakeLists.txt#L44
1:49 PM
Building everything together will generate extension binaries that will have no dependencies on the system and allow you to redistribute them (this is especially important for Linux)
y

Yves Dolce

01/24/2020, 8:49 PM
1. Thanks but that https://github.com/osquery/osquery/blob/master/osquery/examples/example_extension.cpp is a good example of what I'm saying.
sdk.h
is at
osquery\sdk\sdk.h
yet it does
#include <osquery/sdk.h>
. 2. I thought that the difference between an extension and a plugin is that the former can be out-of-proc, independently built from osquery (although it does need to reference some files from it). Am I wrong?
a

alessandrogario

01/24/2020, 11:45 PM
Normally there is a 1:1 match between the fs structure and what is used in the #include directive. WIth osquery this no longer applies. This is something that has been introduced by Buck (include namespaces), and we had to emulate it with CMake.
11:46 PM
Personally, I don’t think it’s a good idea - and we should place the files in the right folders from the start. No having this can and will cause issues with other tools (such as analysis tools)
11:46 PM
In the long past, osquery had modules; today, an extension is just a collection of plugins
11:47 PM
plugins can be tables, config providers, loggers, etc
11:47 PM
regardless, they are always in the core (osqueryd/osqueryi) or inside another executable (never a DLL/.so file)
y

Yves Dolce

01/24/2020, 11:49 PM
Thanks. I see. Doesn't it mean that the doc needs to be updated?
a

alessandrogario

01/24/2020, 11:50 PM
If the documentation is different compared to the example file, yes. we should open a ticket about it
y

Yves Dolce

01/25/2020, 12:00 AM
For example, is your comment (about the fs structure) anywhere in the doc so that someone wanting to develop an out-of-proc plugin would know?
a

alessandrogario

01/25/2020, 12:00 AM
what do you mean with “out of proc”?
12:00 AM
out of the osquery source tree?
y

Yves Dolce

01/25/2020, 12:01 AM
An EXE,not a DLL.
a

alessandrogario

01/25/2020, 12:01 AM
there is no other way, only executables are supported
12:02 AM
only the single supported method is documented
y

Yves Dolce

01/25/2020, 12:03 AM
Instead of DLL, I should have said compiled into OSQUERY.
12:04 AM
So back to my point about the doc: shouldn't something like your comment (filesystem) be in the doc?
a

alessandrogario

01/25/2020, 12:05 AM
CMake and Buck will make sure that the include directive for the sdk.h file works
12:05 AM
I’m not sure how to document the internals of this
12:05 AM
this “feature” of Buck was kind of forced on master
y

Yves Dolce

01/25/2020, 12:05 AM
I see. Thanks.
1:34 AM
I still would like to be able to build a small console program that uses
ExtensionManagerClient
, with VS, outside the
osquery
folder tree. Is this possible?