SG 6.2.2 trying to read jvm.options.dpkg-dist on startup

Search Guard
1

After an upgrade of ES to 6.2.2, we find we have a file named jvm.options.dpkg-dist, as our jvm.options file is modified and pushed with puppet.
On startup, SG is trying to read this file, and failing, causing elasticsearch to not start.
The read failure is due to the permissions on jvm.options.dpkg-dist being set root:elasticsearch 600 by dpkg.
The question is, why is SG trying to read this file in the first place? It’s irrelevant and does not contain any info for our environment.

We could fix this by having puppet set the permissions correctly on this file, but that seems unnecessary for a file we don’t want to read anyway.

Thanks,
CK

  • Search Guard and Elasticsearch version: 6.2.2

  • Installed and used enterprise modules, if any: no modules

  • JVM version: openjdk-8-jre-headless:amd64 8u151-b12-0ubuntu0.16.04.2

  • Operating system version: Ubuntu 16.04.3 LTS

  • Search Guard configuration files: n/a

  • Other installed Elasticsearch or Kibana plugins, if any: none

  • Elasticsearch log messages on debug level:

[2018-02-27T11:20:39,251][ERROR][c.f.s.SearchGuardPlugin ] ElasticsearchSecurityException[Unable to digest file]; nested: AccessDeniedException[/etc/elasticsearch/jvm.options.dpkg-dist];
[2018-02-27T11:20:39,262][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [hostname] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: failed to load plugin class [com.floragunn.searchguard.SearchGuardPlugin]
[…stack trace…]

2

Hi,

we do not read any file in the config directory, apart from what is configured in elasticsearch.yml (certificates, keys etc.). It seems this is happening in the Elastic code when it tries to instantiate plugins. My guess is that this would happen also with other plugins. We would need to see the full stack trace of this error to locate where it originally comes from.

···

On Monday, February 26, 2018 at 11:46:12 PM UTC+1, CK wrote:

After an upgrade of ES to 6.2.2, we find we have a file named jvm.options.dpkg-dist, as our jvm.options file is modified and pushed with puppet.
On startup, SG is trying to read this file, and failing, causing elasticsearch to not start.
The read failure is due to the permissions on jvm.options.dpkg-dist being set root:elasticsearch 600 by dpkg.
The question is, why is SG trying to read this file in the first place? It’s irrelevant and does not contain any info for our environment.

We could fix this by having puppet set the permissions correctly on this file, but that seems unnecessary for a file we don’t want to read anyway.

Thanks,
CK

  • Search Guard and Elasticsearch version: 6.2.2
  • Installed and used enterprise modules, if any: no modules
  • JVM version: openjdk-8-jre-headless:amd64 8u151-b12-0ubuntu0.16.04.2
  • Operating system version: Ubuntu 16.04.3 LTS
  • Search Guard configuration files: n/a
  • Other installed Elasticsearch or Kibana plugins, if any: none
  • Elasticsearch log messages on debug level:

[2018-02-27T11:20:39,251][ERROR][c.f.s.SearchGuardPlugin ] ElasticsearchSecurityException[Unable to digest file]; nested: AccessDeniedException[/etc/elasticsearch/jvm.options.dpkg-dist];
[2018-02-27T11:20:39,262][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [hostname] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: failed to load plugin class [com.floragunn.searchguard.SearchGuardPlugin]
[…stack trace…]

3

Sorry, I was actually wrong. What we do here is: we scan the directory for our demo certificates and refuse to start if they are found and not allowed explicitly. This is a safety net to avoid that customers use the unsafe demo certificates in production.

We can address this issue in the next release, can you please open an issue here?

Thanks.

···

On Tuesday, February 27, 2018 at 11:35:42 AM UTC+1, Jochen Kressin wrote:

Hi,

After an upgrade of ES to 6.2.2, we find we have a file named jvm.options.dpkg-dist, as our jvm.options file is modified and pushed with puppet.
On startup, SG is trying to read this file, and failing, causing elasticsearch to not start.
The read failure is due to the permissions on jvm.options.dpkg-dist being set root:elasticsearch 600 by dpkg.
The question is, why is SG trying to read this file in the first place? It’s irrelevant and does not contain any info for our environment.

We could fix this by having puppet set the permissions correctly on this file, but that seems unnecessary for a file we don’t want to read anyway.

Thanks,
CK

  • Search Guard and Elasticsearch version: 6.2.2
  • Installed and used enterprise modules, if any: no modules
  • JVM version: openjdk-8-jre-headless:amd64 8u151-b12-0ubuntu0.16.04.2
  • Operating system version: Ubuntu 16.04.3 LTS
  • Search Guard configuration files: n/a
  • Other installed Elasticsearch or Kibana plugins, if any: none
  • Elasticsearch log messages on debug level:

[2018-02-27T11:20:39,251][ERROR][c.f.s.SearchGuardPlugin ] ElasticsearchSecurityException[Unable to digest file]; nested: AccessDeniedException[/etc/elasticsearch/jvm.options.dpkg-dist];
[2018-02-27T11:20:39,262][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [hostname] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: failed to load plugin class [com.floragunn.searchguard.SearchGuardPlugin]
[…stack trace…]

we do not read any file in the config directory, apart from what is configured in elasticsearch.yml (certificates, keys etc.). It seems this is happening in the Elastic code when it tries to instantiate plugins. My guess is that this would happen also with other plugins. We would need to see the full stack trace of this error to locate where it originally comes from.

On Monday, February 26, 2018 at 11:46:12 PM UTC+1, CK wrote: