我正试图通过Dockerfile
禁用随机化:
RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
但我得到
Step 9 : RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
---> Running in 0f69e9ac1b6e
[91mtee: /proc/sys/kernel/randomize_va_space: Read-only file system
以任何方式解决这个问题? (我看到它说read-only file system
以任何方式解决这个问题?)如果kernel
做了什么,这意味着它超出了我的container
范围,在这种情况下,我应该如何在我的容器内使用gdb?请注意,这是我在容器中使用gdb
的目标,因为我正在尝试使用它,所以我想要一个container
封装gcc
和gdb
用于实验。
答案 0 :(得分:1)
Docker有syntax for modifying some of the sysctls(虽然不是通过dockerfile),而似乎不是其中之一。
既然您已经说过对运行gcc / gdb感兴趣,可以disable ASLR only for these binaries使用:
kernel.randomize_va_space
另请参阅this question中的其他答案。
答案 1 :(得分:1)
在主机 运行:
sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
不在码头
答案 2 :(得分:0)
听起来您正在自己的计算机上构建一个用于开发的容器。与生产环境不同,您可以(并且可能应该)选择 privileged container。在特权容器中,sysfs
以读写方式挂载,因此您可以像在主机上一样控制内核参数。这是我用来在我的 Debian 桌面上开发的 Amazon Linux 容器的示例,它显示了不同之处
$ docker run --rm -it amazonlinux
bash-4.2# grep ^sysfs /etc/mtab
sysfs /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
bash-4.2# exit
$ docker run --rm -it --privileged amazonlinux
bash-4.2# grep ^sysfs /etc/mtab
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
bash-4.2# exit
$
注意 ro
在非特权情况下挂载,在特权情况下 rw
。
注意Dockerfile命令
RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
没有意义。它将在 (a) 容器构建期间 (b) 在您构建映像的机器上执行。您希望 (a) 在容器运行时发生,以及 (b) 在运行容器的机器上发生。如果您需要在映像启动时更改 sysctls,请编写一个脚本来完成所有设置,然后将您放入交互式 shell,例如将脚本放入例如/root 并将其设置为入口点
#!/bin/sh
sudo sysctl kernel.randomize_va_space=0
exec /bin/bash -l
(假设您将主机工作目录挂载到 /home/jas
中,这是一个很好的做法,因为 bash 会读取您的启动文件等)。
您需要确保容器内的 UID 和 GID 相同,并且可以执行 sudo
。如何启用 sudo 取决于发行版。在 Debian 中,sudo
组的成员拥有不受限制的 sudo 访问权限,而在 Amazon Linux(以及 IIRC、其他类似 RedHat 的系统上,组 wheel
拥有。通常这归结为一个笨拙的运行命令您更愿意编写脚本而不是键入,例如
docker run -it -v $HOME:$HOME -w $HOME -u $(id -u):$(id -g) --group-add wheel amazonlinux-devenv
由于您的主 UID 和 GID 与主机匹配,因此挂载的主机目录中的文件最终不会归 root 所有。另一种方法是在映像构建期间(即在 Dockerfile 中)为自己创建一个真正的用户,但我发现这更容易出错,因为我最终可以运行此 devenv
映像,其中我的用户名具有不同的 UID ,这会导致问题。在启动命令中使用 id(1) 保证 UID 匹配。