Re: Does selinux work with kernel namespaces?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Then updating to docker-ce again via the docker instructions:

https://docs.docker.com/install/linux/docker-ce/centos/#set-up-the-repository

Then I get:

[root@localhost ~]# docker run hello-world
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:296: starting container process caused
"process_linux.go:301: running exec setns process for init caused
\"exit status 40\"": unknown.

Which leads me to:

https://github.com/moby/moby/issues/35336

Which suggests that centos 7.4 doesn't support namespaces with docker,
but one might be able to test by adding:

namespace.unpriv_enable=1

I add that but still get:

[root@localhost ~]# setenforce 0
[root@localhost ~]# docker run hello-world
docker: Error response from daemon: OCI runtime create failed:
container_linux.go:296: starting container process caused
"process_linux.go:301: running exec setns process for init caused
\"exit status 40\"": unknown.

So maybe this just doesn't work yet.


On Fri, Feb 9, 2018 at 7:19 PM, Matt Callaway <matt.callaway@xxxxxxxxx> wrote:
> I joined the selinux list and sent the above, but I have not seen it posted.
>
> I rebuilt my test system with stock centos 7.4 with the docker that it
> comes with and the kernel that it comes with. It runs fine before
> enabling userns-remap:
>
> [root@localhost ~]# uname -r
> 3.10.0-693.17.1.el7.x86_64
> [root@localhost ~]# cat /etc/redhat-release
> CentOS Linux release 7.4.1708 (Core)
> [root@localhost ~]# docker --version
> Docker version 1.12.6, build 3e8e77d/1.12.6
> [root@localhost ~]# grep 3.10.0-693.17.1.el7.x86_64 /boot/grub2/grub.cfg
> menuentry 'CentOS Linux (3.10.0-693.17.1.el7.x86_64) 7 (Core)' --class
> centos --class gnu-linux --class gnu --class os --unrestricted
> $menuentry_id_option
> 'gnulinux-3.10.0-693.11.6.el7.x86_64-advanced-3ac2b526-6c37-46f7-8539-67bc4e55dd49'
> {
> linux16 /vmlinuz-3.10.0-693.17.1.el7.x86_64
> root=/dev/mapper/VolGroup00-LogVol00 ro no_timer_check console=tty0
> console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 crashkernel=auto
> rd.lvm.lv=VolGroup00/LogVol00 rd.lvm.lv=VolGroup00/LogVol01 rhgb quiet
> LANG=en_US.UTF-8 user_namespace.enable=1 namespace.unpriv_enable=1
> initrd16 /initramfs-3.10.0-693.17.1.el7.x86_64.img
> [root@localhost ~]# docker run hello-world | head -n2
>
> Hello from Docker!
>
> Then when I add userns-remap it fails:
>
> [root@localhost ~]# cat /etc/docker/daemon.json
> {
>   "userns-remap": "default"
> }
> [root@localhost ~]# systemctl restart docker
> [root@localhost ~]# docker run hello-world
> nsenter: unable to unshare namespaces: Invalid argument
> container_linux.go:247: starting container process caused
> "process_linux.go:245: running exec setns process for init caused
> \"exit status 1\""
> /usr/bin/docker-current: Error response from daemon: invalid header
> field value "oci runtime error: container_linux.go:247: starting
> container process caused \"process_linux.go:245: running exec setns
> process for init caused \\\"exit status 1\\\"\"\n".
>
>
> This symptom is reported here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1441993
>
> CLOSED INSUFFICIENT_DATA
>
> Mr. Walsh commented in that:
>
> Daniel Walsh 2017-04-13 09:15:06 EDT
>
> "Why would usernamespace be required for this?  You might want to try
> user namespace with docker-latest, but as of now we don't support user
> namespace on RHEL."
>
> But that was obviously several months ago.
>
> Also similar here:
>
> https://github.com/moby/moby/issues/25929
>
> But that suggests adding:
>
> user_namespace.enable=1
>
> which I've done already:
>
> [root@localhost ~]# grep user_namespace.enable /proc/cmdline
> BOOT_IMAGE=/vmlinuz-3.10.0-693.17.1.el7.x86_64
> root=/dev/mapper/VolGroup00-LogVol00 ro no_timer_check console=tty0
> console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 crashkernel=auto
> rd.lvm.lv=VolGroup00/LogVol00 rd.lvm.lv=VolGroup00/LogVol01 rhgb quiet
> LANG=en_US.UTF-8 user_namespace.enable=1 namespace.unpriv_enable=1
>
> I feel like this problem must be solved, but it doesn't appear solved
> with the "stock" system.
>
> Thoughts?




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux