Option to run ES as root not recognized

[dizzydis]

Elasticsearch version:
5.0.0-alpha2

JVM version:
openjdk version "1.8.0_51"
OpenJDK Runtime Environment (build 1.8.0_51-b16)
OpenJDK 64-Bit Server VM (build 25.51-b03, mixed mode)

OS version:
uname -a
Linux ***** 2.6.32-504.8.1.el6.centos.plus.x86_64 # 1 SMP Wed Jan 28 20:58:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:
It was found, in previous versions, that to run Elasticsearch as root (Even though not recommended) was possible by running bin/elasticsearch with the -Des.insecure.allow.root=true option set.

I am unable to run ES as root in the new versions using this param. On the command line, it outputs the following:

(18:27:48)-> bin/elasticsearch -Des.insecure.allow.root=true
starts elasticsearch

Option             Description
------             -----------
-E <KeyValuePair>  Configure an Elasticsearch setting
-V, --version      Prints elasticsearch version
                     information and exits
-d, --daemonize    Starts Elasticsearch in the background
-h, --help         show help
-p, --pidfile      Creates a pid file in the specified
                     path on start
-s, --silent       show minimal output
-v, --verbose      show verbose output
ERROR: D is not a recognized option

I tried setting the option in the java.options file and I see that it is correctly passing the if check on line 90 of Bootstrap.java evident by the log output, however, it then throws an 'unknown setting' error for IllegalArgumentException (log output below).

Provide logs (if relevant):

[2016-06-01 18:27:45,920][WARN ][bootstrap                ] running as ROOT user. this is a bad idea!
[2016-06-01 18:27:45,947][WARN ][bootstrap                ] unable to install syscall filter:
java.lang.UnsupportedOperationException: seccomp unavailable: requires kernel 3.5+ with CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER compiled in
        at org.elasticsearch.bootstrap.Seccomp.linuxImpl(Seccomp.java:335)
        at org.elasticsearch.bootstrap.Seccomp.init(Seccomp.java:616)
        at org.elasticsearch.bootstrap.JNANatives.trySeccomp(JNANatives.java:215)
        at org.elasticsearch.bootstrap.Natives.trySeccomp(Natives.java:99)
        at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:99)
        at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:152)
        at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:267)
        at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:111)
        at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:106)
        at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:91)
        at org.elasticsearch.cli.Command.main(Command.java:53)
        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:74)
        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:67)
[2016-06-01 18:27:46,500][INFO ][node                     ] [pet-LAB2-1] version[5.0.0-alpha2], pid[16464], build[e3126df/2016-04-26T12:08:58.960Z]
[2016-06-01 18:27:46,500][INFO ][node                     ] [pet-LAB2-1] initializing ...
[2016-06-01 18:27:47,216][INFO ][plugins                  ] [pet-LAB2-1] modules [lang-mustache, lang-painless, ingest-grok, reindex, lang-expression, lang-groovy], plugins []
[2016-06-01 18:27:47,265][INFO ][env                      ] [pet-LAB2-1] using [1] data paths, mounts [[/ (/dev/mapper/vg_centos66template-lv_root)]], net usable_space [37.2gb], net total_space [43.6gb], spins? [possibly], types [ext4]
[2016-06-01 18:27:47,265][INFO ][env                      ] [pet-LAB2-1] heap size [1007.3mb], compressed ordinary object pointers [true]
[2016-06-01 18:27:48,274][ERROR][bootstrap                ] Exception
java.lang.IllegalArgumentException: unknown setting [insecure.allow.root]
        at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:267)
        at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:238)
        at org.elasticsearch.common.settings.SettingsModule.configure(SettingsModule.java:120)
        at org.elasticsearch.common.inject.AbstractModule.configure(AbstractModule.java:60)
        at org.elasticsearch.common.inject.spi.Elements$RecordingBinder.install(Elements.java:233)
        at org.elasticsearch.common.inject.spi.Elements.getElements(Elements.java:103)
        at org.elasticsearch.common.inject.InjectorShell$Builder.build(InjectorShell.java:148)
        at org.elasticsearch.common.inject.InjectorBuilder.build(InjectorBuilder.java:99)
        at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:96)
        at org.elasticsearch.common.inject.Guice.createInjector(Guice.java:70)
        at org.elasticsearch.common.inject.ModulesBuilder.createInjector(ModulesBuilder.java:46)
        at org.elasticsearch.node.Node.<init>(Node.java:235)
        at org.elasticsearch.node.Node.<init>(Node.java:161)
        at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:188)
        at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:188)
        at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:267)
        at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:111)
        at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:106)
        at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:91)
        at org.elasticsearch.cli.Command.main(Command.java:53)
        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:74)
        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:67)

[jasontedor]

Sorry for the chaos here. Elasticsearch previously permitted multiple ways of specifying settings and system properties, and entangled system properties and settings (each got converted to the other). Additionally, settings use to be extremely lenient.

In Elasticsearch 5.0.0, we are attempting to make progress on these fronts. Now, all settings must be registered. Additionally, we have removed some of the multiple ways of specifying settings and system properties, and removed the entanglement between settings and system properties. Some of that work was in-progress when 5.0.0-alpha2 shipped. That's what you're running into here.

In particular, you can't pass system properties as -D arguments to Elasticsearch anymore. Instead, you have to pass them as Java options, as you figured out. The next problem though is the system properties and settings entanglement. In particular, system properties would get converted to Elasticsearch settings. But all settings must be registered, and insecure.allow.root is not a registered setting. Thus, the failure.

In 5.0.0-alpha3, all of this has been cleaned up. The entanglement between system properties and settings has been removed. This means that the system property es.insecure.allow.root will not automatically be converted to a setting which means it's no longer a problem that it's not registered.

The 5.0.0-alpha3 was released yesterday and is free of this problem. If you have a chance to download and try it out, I'd appreciate feedback on whether or not it worked out for you.

That said, I would like to know your use case for running as root? I think that eventually it would be nice if we could remove this functionality while continuing to disallow running as root.

[dizzydis]

I'll DL apha3 right now and re-test. Sorry about that.

As for my use case, I wish I had a great one for you. I ended up running into a lot of one-off issues that were just more easily resolved by running as root. If I recall it had something to do with the fact that I was installing via the tar/zip files, and they did not include init scripts (like the Repo versions do), so I had written my own, and wasn't able, at the time, to figure out how to get an init script to run the process as a different user other than root.
Once I got into a working state, I've worked on more pressing issues. The risks did not outweigh the time it would take to fix. It's something I will probably change eventually - possibly even for my 5.0 migration when that times comes. As for right now, I've just been shooting for as close to 'backwards compatible' as I can get for my testing.
I do have on my to-do list to drop in the init scripts delievered with the repo versions, (and eventually switch over to installing from the repo instead of the downloaded packages), and I imagine that will be a big step for me to be able to use without root.

[jasontedor]

Thanks for the feedback @dayjavid! 😄

I had written my own, and wasn't able, at the time, to figure out how to get an init script to run the process as a different user other than root.

The reason that the services must be started as the root user is exactly so that the scripts can launch the processes as the elasticsearch user.

I imagine that will be a big step for me to be able to use without root.

It sounds like it might be okay then if we push to remove this sooner rather than later. Am I reading you correctly?

[dizzydis]

I will make sure that when I migrate to 5.0 I will be able to run as non-root, yes.

[clintongormley]

Sounds like there is nothing left to do here, closing

[jasontedor]

I will make sure that when I migrate to 5.0 I will be able to run as non-root, yes.

Thanks @dayjavid. 😄