How to disable linux space randomization via dockerfile?

In hostrun:

sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

not in docker

Docker has syntax for modifying some of the sysctls (not via dockerfile though) and kernel.randomize_va_space does not seem to be one of them.

Since you've said you're interested in running gcc/gdb you could disable ASLR only for these binaries with:

setarch `uname -m` -R /path/to/gcc/gdb

Also see other answers in this question.

Sounds like you are building a container for development on your own computer. Unlike production environment, you could (and probably should) opt for a privileged container. In a privileged container sysfs is mounted read-write, so you can control kernel parameters as you would on the host. This is an example of Amazon Linux container I use to develop for on my Debian desktop, which shows the difference

$ docker run --rm -it amazonlinuxbash-4.2# grep ^sysfs /etc/mtabsysfs /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0bash-4.2# exit$ docker run --rm -it --privileged amazonlinuxbash-4.2# grep ^sysfs /etc/mtabsysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0bash-4.2# exit$

Notice ro mount in the unprivileged, rw in the privileged case.

Note that the Dockerfile command

RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

makes no sense. It will be executed (a) during container build time (b) on the machine where you build the image. You want (a) happen at container's run time and (b) on the machine where you run the container. If you need to change sysctls on image start, write a script which does all the setup and then drops you into the interactive shell, like placing a script into e.g. /root and setting it as the ENTRYPOINT

#!/bin/shsudo sysctl kernel.randomize_va_space=0exec /bin/bash -l

(Assuming you mount host working directory into /home/jas that's a good practice, as bash will read your startup files etc).

You need to make sure you have the same UID and GID inside the container, and can do sudo. How you enable sudo depends on a distro. In Debian, members of the sudo group have unrestricted sudo access, while on Amazon Linux (and, IIRC, other RedHat-like system, the group wheel has. Usually this boils down to an unwieldy run command that you rather want to script than type, like

docker run -it -v $HOME:$HOME -w $HOME -u $(id -u):$(id -g) --group-add wheel amazonlinux-devenv

Since your primary UID and GID match the host, files in mounted host directories won't end up owned by root. An alternative is create a bona fide user for yourself during image build (i.e., in the Dockerfile), but I find this more error-prone, because I can end up running this devenv image where my username has a different UID, and that will cause problems. The use of id(1) in a startup command guarantees UID match.