https://github.com/osquery/osquery logo
Join Slack
Powered by
Switching topic. Developing an extension (not a pl...
# windows
y
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
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
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
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
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.
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)
In the long past, osquery had modules; today, an extension is just a collection of plugins
plugins can be tables, config providers, loggers, etc
regardless, they are always in the core (osqueryd/osqueryi) or inside another executable (never a DLL/.so file)
y
Thanks. I see. Doesn't it mean that the doc needs to be updated?
a
If the documentation is different compared to the example file, yes. we should open a ticket about it
y
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
what do you mean with “out of proc”?
out of the osquery source tree?
y
An EXE,not a DLL.
a
there is no other way, only executables are supported
only the single supported method is documented
y
Instead of DLL, I should have said compiled into OSQUERY.
So back to my point about the doc: shouldn't something like your comment (filesystem) be in the doc?
a
CMake and Buck will make sure that the include directive for the sdk.h file works
I’m not sure how to document the internals of this
this “feature” of Buck was kind of forced on master
y
I see. Thanks.
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?
4 Views
Open in Slack
PreviousNext
Powered by