cap-add=NET_ADMIN on aws ecs about docker-dnsmasq

[borgstrom]

For anyone else ending up here when trying to get dnsmasq running in ECS:

Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514214#10

You can use --user=root to avoid the need to run as a privileged container.

[andyshinn]

@borgstrom, while I didn't generally agree with #11, it could make sense to mention this in the README. I'm going to close this issue as the original one is more specific to AWS. But I'd be happy to accept a pull request to add something to the README mentioning adding --user=root to their CMD in lieu of --privileged or --cap-add.

[andyshinn]

I forget what was failing. Can you try and see? It might have been the binding of ports < 1024 per http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008540.html.

[MFProduction]

I used --privileged flag and it's working, but i don't think that's a good idea from the security perspective?

[andyshinn]

Security is different for everyone. I can't really comment on that specifically. But understanding why we need to use --privileged or -cap-add NET_ADMIN could be helpful to all. If it was something as simple as binding to port 53 then we could probably change that to 5300 in the container and use port mapping externally to do 53:5300 and you wouldn't need any privileged mode.

[MFProduction]

FAQ on dnsmasq says that NET_ADMIN is essential; and from what i could gather for iptables and port bindings.
What i found is that if i run -k -d without -cap-add NET_ADMIN it working so maybe it's one of this:

-d, --no-daemon
Debug mode: don't fork to the background, don't write a pid file, don't change user id, generate a complete cache dump on receipt on SIGUSR1, log to stderr as well as syslog, don't fork new processes to handle TCP queries. Note that this option is for use in debugging only, to stop dnsmasq daemonising in production, use -k.

[andyshinn]

Unfortunately, I don't have a good answer. I don't use this image anymore and don't have good understanding of the Linux capabilities. I tired to narrow down the capabilities when I originally used it so that it didn't require --privileged. I found that NET_ADMIN was the best compromise. But if --privileged is available and you understand the security implications (of which I can't really talk to) then that would be a workaround as I was originally running it with --privileged before I found NET_ADMIN working.

If you or anyone else find otherwise, feel free to open a pull request to modify the README accordingly.

[MFProduction]

I will probably run it in --privileged because the container is running on private network.
Thanks for help.