osquery / osquery/osquery

Windows MSI installer overwrites default config files during upgrade

Open
#6,891 0 comments 0 reactions 1 assignee View on GitHub

@muffins is already working on this.

Since Jan 10, 2021.

configuration deployment user experience Windows
Dominant language
C++
Stars
23.6k
Forks
2.6k
Avg merge
6d 7h
Merged PRs (30d)
14

Description

Bug report

What operating system and version are you using?
version = 10.0.19042
build = 19042
platform = windows
What version of osquery are you using?

version = 4.6.0.2

What steps did you take to reproduce the issue?
  1. Installed osquery 4.5.1 using the "official" MSI
  2. Updated both files osquery.conf and osquery.flags
  3. Installed osquery 4.6.0.2 using the installer provided by osquery.io
What did you expect to see?

I was expecting I would be able to either edit or deploy my own osquery.conf, osquery.flags and certs\certs.pem and that these would remain untouched after a client upgrade.

What did you see instead?

The files were deleted and new ones were installed. My changes were lost.

Additional background information

We currently deploy osquery using an MDM (Meraki) which installs the official MSI files which are pulled directly from the official sources into the clients and the these are run silently on the client devices.
The MSI files install the service automatically into the devices pointing the service to the default flag file at C:\Program Files\osquery\osquery.flags.
We then deploy our own certs, flags file, config and secret via a separate installer replacing the default files. The current behaviour of overwriting these config files during upgrade breaks our workflow as we can't ensure the config is later deployed just after the client is upgraded.

My suggestion would be to either create these "default" configuration files if these don't exist already and keep them untouched if already present. The most important one would be the flags file that the service points to as with this one we can point to a different config, secret, certificate, etc... in alternative paths.

I understand the current behaviour would be perfect for those that create custom packages with their own config, flags and certs embedded into the msi but this might cause issues to those using the default provided ones.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.