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

osquery

This is related to <https://github.com/osquery/osquery/pull/6663> . Would people be against always requiring explicit configuration to enable publishers/subscribers?

We had some tables in the past that would auto-activate in one way or the other, causing confusion and sometimes even performance issues (events being gathered by mistake on high load systems with no queries running against those tables, causing new events to be written while mass expiration was occurring)

This will help when we just want to have audit based FIM. We use only process(audit) based FIM and inotify/FSWatcher based FIM is enabled even when the file_events table is disabled.  It cause many file handles to be opened even when inotify/ is not being used. A mechanism to turn it off will be useful.

I think it is a good idea to have each subscriber explicitly enabled.

I am not sure if we should add a flag for each subscriber or find another way to explicitly enable them (such as a new configuration object).

(Sidebar, we should hack together a way to have each `--disable*` also respect a `--enable*` and vise-a-versa. I say this because we are not consistent with using one or another.)

Can't we just take a default: everything disabled?
Then our flags can be `--enable*`. Although at the same time, given that the enable flags for events are growing in number, we could just have a flag with a list of table names to enable, instead of a one flag per table.
Then we can maybe keep one flag per feature of a single table.
Like maybe a table can get multiple events type, and you want to enable only some.

Configuration like that would be great assuming it can be controlled by both command line and server endpoint

we've had issues in the past where stuff like hardware was enabled without us realizing/SELECTing leading to negative performance impact

re: "Then our flags can be `--enable*` ", yes but we would want to handle backwards compatibility for existing configurations/flagfiles/etc that use the existing `--disable*` versions. I am thinking generically for all of these types of flags in the tool.

I am in favor of disabling everything by default, and then supporting flags to enable.

I am in favor of creating  disable/enable flag parity.

I am ambivalent if the events should have an enable flag per &lt;thing&gt; or a single flag with comma separated options. My guess is a flag per thing.

I think those enable flags should be allowed in the config file.

I am ambivalent if we need an --enable-everything flag