Skip to content

Allow to run as root / different user #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pazoozooCH opened this issue Apr 9, 2015 · 20 comments
Closed

Allow to run as root / different user #11

pazoozooCH opened this issue Apr 9, 2015 · 20 comments

Comments

@pazoozooCH
Copy link

Is there a compelling reason not to run Logstash in the container as root?

The problem is that the logstash user 999 will not be able to run most logs (like /log/syslog). I think it's better to run root in a Docker container and mount the volume as read-only as to change file permission in the host to allow a non-root docker user to read the logs.

I would suggest just skipping the gosu or add the functionality to specify a user ID to run as when starting the container (through an env variable)...

@yosifkit
Copy link
Member

yosifkit commented Apr 9, 2015

The reasoning is security. Root in a container is equal to root on the host. If there was a vulnerability that allowed a breakout from the docker "container" that would give an attacker root access to the host. There is a similar discussion to adding a way to specify the running user for elasticsearch (docker-library/elasticsearch#14).

@pazoozooCH
Copy link
Author

Hm, seems partially contradictory: "root in a container is equal to root on the host" and "if there WAS a vulnerability..." ;-) I guess if that vulneratiblity isn't there, it's not at all equal, is it?

Anyway, would you be willing to support a RUN_AS_ROOT or RUN_AS env variable for those willing to accept the security risk and opt in to run as root (or another user/group)?

@ei-grad
Copy link

ei-grad commented Apr 13, 2015

Isn't the docker run --user option made for this?.. Using gosu to drop priveledges is absolutely useless ugly hack.

@tianon
Copy link
Member

tianon commented Apr 13, 2015 via email

@pazoozooCH
Copy link
Author

Is there currently a workaround or a best practice to actually just read logs on a volume that do not have read permissions set for everybody? If not, I think we definitely need a way to change the user logstash runs with, otherwise we lose the ability to perform a lot of file based use-cases without making changes to permissions on the host which is not really desirable.

@yosifkit
Copy link
Member

@pazoozooCH, how are file permissions for logstash handled normally outside docker? Does logstash just run as root to see all the logs?

And, yes container root does equal host root: alias sudo='docker run -it --rm -v /:/host --privileged --net=host --pid=host debian chroot /host /bin/bash'.

@ei-grad
Copy link

ei-grad commented Apr 14, 2015

so that we can fix permissions

That is even more awful, btw.

@pazoozooCH
Copy link
Author

@yosifkit, in this case, I'd probably add the logstash user to the adm group so it could read the system logs without me having to change default permissions of Ubuntu. In this case, I'd require an option to specify a "run-as group".

Well, your example is not really that realistic. Obviously, I wouldn't just mount / into my container and run it as root. I would mount /var/log as readonly into the container and trust docker to actually run it in a container/sandbox that is not escapable... If that actually works (and if it doesn't, Docker would have a BIG problem), I don't see that much of a problem running root INSIDE the container.

@pazoozooCH
Copy link
Author

btw, as I've indicated in #10, $HOME for the logstash user currently stays /root, causing problems with Logstash's default settings INSIDE the container. I think the whole user management should be improved on anyway...

@viranch
Copy link

viranch commented May 11, 2015

I found a workaround after reading the entrypoint script: give anything other than logstash as first argument to the docker run command, e.g. full path to it :)

Run as root:

$ docker run -d --name logstash logstash /opt/logstash/bin/logstash agent -e 'input { stdin { } } output { stdout { } }'
$ docker exec logstash ps aux
USER     PID
root     1

Run as user foo:

docker run -d --name logstash --user foo logstash /opt/logstash/bin/logstash agent -e 'input { stdin { } } output { stdout { } }'

@yosifkit
Copy link
Member

Would something like docker-library/elasticsearch#77 be helpful to allow you to specify any non-root user and group to run as, using the --user flag on docker run? It seems like @viranch's trick would allow you to run as root.

@EamonZhang
Copy link

Hi , how to run , with user logstash
input {
file{ path => "/var/log/nginx/access.log" }
}

,
even chmod 777 access.log

Thanks.

@yosifkit
Copy link
Member

@EamonZhang, what about the permissions on the directory /var/log/nginx/?

@EamonZhang
Copy link

@yosifkit drw-rw-rw-

It say no permissions at first, then I change it to drw-rw-rw- with command chmod 666 /var/log/nginx -R

It does not show permissions problem.

but can use , echo "some thing " > /var/log/nginx/access.log . logstash is not responding.

I notice docker-entrypoint.sh change the user.

I start logstash bypass docker-entrypoint.sh, use root user. It seems ok.

@mattupstate
Copy link

mattupstate commented Jul 25, 2016

One side effect of this is that the S3 output plugin will cause the Logstash process to fail to start because during the plugin's registration phase it attempts to write a temporary file to /tmp/logstash/s3/logstash-programmatic-access-test-object-<a short uid> and the logstash user does not have permission to write to this location. As a result one can't run a container with this image without overriding the entrypoint and you'll experience the following error:

{:timestamp=>"2016-07-25T03:42:16.635000+0000", :message=>"Pipeline aborted due to error", :exception=>#<Errno::EACCES: Permission denied - /tmp/logstash/s3/logstash-programmatic-access-test-object-1469418136>, :backtrace=>["org/jruby/RubyFile.java:370:in `initialize'", "org/jruby/RubyIO.java:1197:in `open'", "/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-output-s3-3.0.1/lib/logstash/outputs/s3.rb:259:in `test_s3_write'", "/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-output-s3-3.0.1/lib/logstash/outputs/s3.rb:236:in `register'", "/usr/share/logstash/logstash-core/lib/logstash/output_delegator.rb:86:in `register'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:184:in `start_workers'", "org/jruby/RubyArray.java:1613:in `each'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:184:in `start_workers'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:139:in `run'", "/usr/share/logstash/logstash-core/lib/logstash/agent.rb:240:in `start_pipeline'"], :level=>:error}

@tukiyo
Copy link

tukiyo commented Aug 5, 2016

docker run  \
 -it --rm -v "$PWD":/config-dir \
 -v /var/log/apache2/:/var/log/apache2/:ro \
 logstash:5 \
- logstash -f /config-dir/logstash.conf

according to the 5.0/docker-entrypoint.sh, to run as root: replace line whitch you like

+ /usr/share/logstash/bin/logstash -f /config-dir/logstash.conf
+ gosu root logstash -f /config-dir/logstash.conf
+ sh -c "logstash -f /config-dir/logstash.conf"

@mi-hol
Copy link

mi-hol commented Nov 28, 2016

@pazoozooCH @tianon looks like this could be closed too, right?

@pazoozooCH
Copy link
Author

@mi-hol , didn't have time to look at it recently - I guess yes...

@tianon
Copy link
Member

tianon commented Nov 28, 2016

Right now, the easiest way to run as non-root is to use --entrypoint -- I've filed a PR to simplify this a little further (#70):

$ docker run --name logstash --user 1000:1000 --entrypoint logstash logstash:5.0 -e '...'

@tianon
Copy link
Member

tianon commented Nov 28, 2016

As noted in #70, I had to also specify --tmpfs /var/lib/logstash so that user 1000 could write to that directory in the container, but it was successful. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants