moby: Cannot build emacs using Dockerfile

Emacs 27 will be able to build inside docker (currently it’s the master branch).

For previous versions, you can use https://hub.docker.com/r/silex/emacs or disable /proc/sys/kernel/randomize_va_space like mentionned above.

@Silex that setfattr -n user.pax.flags would be only for a PaX setup, which is not that common.

For some more comments on the horrible emacs build process see http://www.openwall.com/lists/musl/2015/02/03/1 which documents the issues building it on Musl libc.

As far as I can see the options are:

1. Do nothing. If you want to build emacs you will have to disable ASLR globally on your machine or for all docker processes, eg globally with docker run --privileged --pid=host alpine sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"
2. Allow disabling ASLR via personality for all processes, which weakens security
3. Allow disabling ASLR only on the seccomp profile for build, but not run, just to allow emacs to build.
4. Allow setting security opts at build time so you can change/disable the seccomp filters for build. This will not allow builds on for example Docker Hub unless they expose these flags, which would be fairly unlikely.

Need to think about which option is best.

cc @jfrazelle

@fommil many people have asked for this misfeature to be optional for a long time, and support for it was nearly removed from glibc at one point, see https://lwn.net/Articles/673724/

@Silex, thanks!

I still have to use the pid=host hack though, because I mount the docker client from moby linux (which docker for windows employs as the linux vm for the docker daemon host). I can’t just echo 0 > blah because the address is read only. Magically, with this hack:

docker run -it --rm --privileged --pid=host alpine sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"

then it works. go figure.

it’s the same, but not really the same in docker for windows.

Well no, you are turning it for the host:

philippe@pv-desktop:~$ cat /proc/sys/kernel/randomize_va_space
2

philippe@pv-desktop:~$ docker run -it --rm --privileged --pid=host centos bash -c "echo 0 > /proc/sys/kernel/randomize_va_space"

philippe@pv-desktop:~$ cat /proc/sys/kernel/randomize_va_space
0

That’s what --pid=host does.

AFAIK docker run -it --rm --privileged --pid=host centos COMMAND is basically a complicated way to do sudo COMMAND 😉

Anyway, even if it worked requiring privileged containers is not a workaround. The docker hub will likely never build with privileged containers.

Also, someone correct me if I’m wrong but ASLR will always be shared between the host and the containers… given the containers share the same kernel.

@ninrod: in effect this is the same as disabling ASLR before building… only with more steps. Also it looks like you don’t restore ASLR in the end so your machine now has ASLR disabled.

This is much simpler:

echo 0 > /proc/sys/kernel/randomize_va_space
docker build -t emacs .
echo 2 > /proc/sys/kernel/randomize_va_space

For information, there’s quite a discussion going on at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23529

The current idea is to simply remove the undump feature in Emacs and replace it with something more straightforward which should not require special privileges.

Link to emacs bug report, but unlikely to be fixed in emacs itself: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23529

We are working on an easier workaround too, will update here soon.

On 14 Sep 2016 3:16 a.m., “Filipe Silva” notifications@github.com wrote:

@cpitclaudel https://github.com/cpitclaudel I did not because I don’t want to run emacs in batch mode. I use emacs for coding and it has to be very fast.

Only way I’m seeing to get this working is to forget about my Dockerfile build and start my base container with docker run --privileged sh -c “echo 0 > /proc/sys/kernel/randomize_va_space”, issue commands through docker exec and commit the final container with docker commit.

I started to scratch this solution in work but had to go home. I think I’ll finish by the end of this week as this is a side project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker/docker/issues/22801#issuecomment-246885579, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdcPNLnO8tHPxyeQwhkeBPWZWfZn5kpks5qp1jggaJpZM4IhA1- .

@fommil Docker Hub recently updated to a more recent version of Docker for builds I believe, and also a newer base distribution, with seccomp enabled, so that is when the change would be from.

I really can’t see a RUN_PRIVILEGED Dockerfile command being accepted, as you would need to know that this was required before running the whole Dockerfile, as once you have started without privilege you cannot escalate.

I also can’t see any service which operates on the internet willingly disabling basic protections like ASLR, so I think it is unlikely that Docker Hub would want to support this as an option.