Make the privilege drop down optional

[ggtools]

As in some situation, it is impossible to execute chown on the
data directory running elasticsearch as the elasticsearch user is
not possible. The entry point now supports to run elasticsearch
as root if the RUN_AS_ROOT environment variable is set to a non
empty string.

Fixes #5

[md5]

How about having : ${ELASTICSEARCH_USER:=elasticsearch} instead of RUN_AS_ROOT?

[md5]

That would imply changing the chown and gosu commands to use $ELASTICSEARCH_USER and skipping them when "$ELASTICSEARCH_USER" = root.

[ggtools]

Yes I thought of this but then I looked at the chown elasticsearch:elasticsearch and I did wonder if I wanted to replace it by:

• chown $ELASTICSEARCH_USER:elasticsearch
• chown $ELASTICSEARCH_USER:$ELASTICSEARCH_USER
• chown $ELASTICSEARCH_USER
• or find the primary group of $ELASTICSEARCH_USER and using it

[yosifkit]

A user might want to make the ability to tack on the group; -e ELASTICSEARCH_USER='999:50' would be the common option.

[ggtools]

Love this @yosifkit so the test would be to check if the user part is root

[yosifkit]

Seems it would also need to check if someone decided to put 0 for root as well.

[ggtools]

Yup. So working on it ...

[md5]

Not to complicate things, but ELASTICSEARCH_GROUP might be clearer.

[md5]

I also just thought about the fact that there will be some inconsistency across the official images in the use of *_USER variables. In the case of postgres, the POSTGRES_USER variable refers to a DB-level user, not a Unix user.

[yosifkit]

I am thinking this change can apply for all "data/server" images (ex: mysql, mongo, elasticsearch, redis, memcached...), so I would like to have it just as -e RUN_AS user:group. That way it is consistent on all the images.

[ggtools]

That's why RUN_AS_XXX might be a little be clearer

[md5]

👍

[yosifkit]

Quick wrench to throw in, would the RUN_AS only apply for running the contained software (in this case elasticsearch) or would it also apply if I run something else in the container (ex: docker run -it --rm -e RUN_AS='999' elasticsearch bash)? I can easily see users get confused either way and we will need to be sure to document it.

[ggtools]

Hmmm interesting ... current it would only apply to elasticsearch, not other commands. I can see your point however one goals of the entry point script was to run elasticsearch with the correct user and then give a bypass for everything else. Since the command would be executed directly you should probably resort to the normal docker mechanism and use -u 999 if you don't want your command to be run as root

[yosifkit]

That is what I was thinking, if they really need to be another user they are root and have gosu or su. We just need to make sure users know that the ENV only applies to running the contained software and that actions like bash will run as root.

[ggtools]

And voilà

[md5]

LGTM

[tianon]

Here's my thoughts on this:

• RUN_AS is a really generic name; more generic than any environment variable we've used in any official image thus far -- my concern with that is people will start thinking it applies in more places than it does, and either wondering why it isn't working or even worse not even noticing that it's not working and thinking that it is
• chown and gosu accept the same syntax for their arguments -- user, uid, user:group, uid:gid, user:gid, uid:group are all reasonable and acceptable for both, so if we do this, having two knobs for it seems like overkill IMO

[ggtools]

I mostly agree with both items however for the first one I don't have any idea of a replacement name.

[ei-grad]

Isn't the docker run --user option made for this?.. Using gosu to drop priveledges is absolutely useless ugly hack. And making chown for all data on the provided volume is a very bad thing, too.

[tianon]

Without the chown, the user we switch to isn't able to write to the directory.

[ei-grad]

It is not the problem, as it could (and should) be easily fixed by user. If he really need to chown. But the --user flag makes it possible to don't make chown at all.

[tianon]

Ok, so what does the user chown to? The username inside the container may not even exist on the host (and if it does, it's not very likely to match UID/GID), so it's going to have to be an arbitrary UID/GID combination, which is very much the opposite of user-friendly.

[ggtools]

I can add some support to make the script work when the container is launched with a --user option but I'm pretty sure the chown and drop privileges thing is probably the easiest way for the user especially in the future when Docker will use the user namespace which will make quite hard to make the chown to the right user from outside the container

[nizsheanez]

Guys, what is the right way to start elasticsearch:2 for now?
I using Docker Toolbox for Mac

With --user:

docker run --user elasticsearch -it -v $(pwd)/es/data:/usr/share/elasticsearch/data -v $(pwd)/es/config:/usr/share/elasticsearch/config elasticsearch
error: failed switching to "elasticsearch": setgroups operation not permitted

Without --user:

docker run -it -v $(pwd)/es/data:/usr/share/elasticsearch/data -v $(pwd)/es/config:/usr/share/elasticsearch/config elasticsearch
Exception in thread "main" java.lang.IllegalStateException: Unable to access 'path.scripts' (/usr/share/elasticsearch/config/scripts)

Guy in last comment https://hub.docker.com/_/elasticsearch/ has same problem

[ironspecs]

bump Seems this thread was abandoned, but the issue is still real.

[yosifkit]

After some discussion offline with @tianon, we are thinking that the best course of action is to gracefully skip operations that require root when the container is not run as root for all official images (as far as is possible). This will allow you to run with --user, but you would be responsible to chown/chmod any files and directories that the process needs.

So, something like:

if [ "$(id -u)" = '0' ]; then
    chown ...
    set -- gosu ...
fi

exec "$@"