Description of problem: After starting a container, a typical way to interact with it is to run "sudo docker exec -t /bin/bash". On Fedora 22, this doesn't work. Version-Release number of selected component (if applicable): docker-1.6.0-3.git9d26a07.fc22.x86_64 How reproducible: Every time Steps to Reproduce: 1. Create a docker container. The one I'm using is based on CentOS5 and is called "c5" 2. Start it: sudo docker start c5 3. Attempt to run a shell on it: sudo docker exec -t c5 /bin/bash Actual results: Nothing happens; including the fact that no error is reported. The exit code is 129. Same results even for "sudo docker exec -t c5 /bin/echo hello". The echo command is successful if the "-t" flag is left off. Expected results: A shell starts. Additional info: Here's log information from journalctl (long lines, apologies). Jun 17 09:56:41 tb12.cfa.harvard.edu docker[3830]: time="2015-06-17T09:56:41-04:00" level=info msg="POST /v1.18/exec/689d92a64c0cf1de7bd46b86a808b656d838968a8accf24f9291526141b56d4d/resize?h=40&w=120" Jun 17 09:56:41 tb12.cfa.harvard.edu docker[3830]: time="2015-06-17T09:56:41-04:00" level=info msg="+job execResize(689d92a64c0cf1de7bd46b86a808b656d838968a8accf24f9291526141b56d4d, 40, 120)" Jun 17 09:56:41 tb12.cfa.harvard.edu audit[9487]: <audit-1400> avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu audit[9487]: <audit-1400> avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu kernel: audit: type=1400 audit(1434549401.525:1038): avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu kernel: audit: type=1400 audit(1434549401.525:1038): avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu kernel: audit: type=1400 audit(1434549401.525:1038): avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu audit[9487]: <audit-1400> avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu kernel: audit: type=1400 audit(1434549401.525:1038): avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu audit[9487]: <audit-1400> avc: denied { read write } for pid=9487 comm="bash" path="/dev/pts/4" dev="devpts" ino=7 scontext=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 Jun 17 09:56:41 tb12.cfa.harvard.edu audit[9487]: <audit-1300> arch=c000003e syscall=59 success=yes exit=0 a0=c20804cae0 a1=c20804caf0 a2=c2080b7440 a3=0 items=0 ppid=3830 pid=9487 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="bash" exe="/bin/bash" subj=system_u:system_r:svirt_lxc_net_t:s0:c313,c355 key=(null) Jun 17 09:56:41 tb12.cfa.harvard.edu kernel: audit: type=1327 audit(1434549401.525:1038): proctitle="(null)" Jun 17 09:56:41 tb12.cfa.harvard.edu audit: <audit-1327> proctitle="(null)" Jun 17 09:56:41 tb12.cfa.harvard.edu docker[3830]: bad file descriptor Jun 17 09:56:41 tb12.cfa.harvard.edu docker[3830]: time="2015-06-17T09:56:41-04:00" level=info msg="-job execResize(689d92a64c0cf1de7bd46b86a808b656d838968a8accf24f9291526141b56d4d, 40, 120) = ERR (1)" Jun 17 09:56:41 tb12.cfa.harvard.edu docker[3830]: time="2015-06-17T09:56:41-04:00" level=error msg="Handler for POST /exec/{name:.*}/resize returned error: bad file descriptor" Jun 17 09:56:41 tb12.cfa.harvard.edu docker[3830]: time="2015-06-17T09:56:41-04:00" level=error msg="HTTP Error: statusCode=500 bad file descriptor"
Other versions: selinux-policy-3.13.1-128.1.fc22.noarch selinux-policy-targeted-3.13.1-128.1.fc22.noarch
Try docker-1.7 release candidates, should fix this problem
Yes, it does.
I'm seeing this now on F22 with: docker.x86_64 1.7.1-8.gitb6416b7.fc22 I can't get a tty inside a docker with this command: docker exec -t -i -u dang <dockername> ls Syslog outputs: Aug 31 09:20:02 revan audit: <audit-1400> avc: denied { read write } for pid=4633 comm="ls" path="/dev/pts/27" dev="devpts" ino=30 scontext=system_u:system_r:svirt_lxc_net_t:s0:c475,c865 tcontext=system_u:object_r:docker_devpts_t:s0 tclass=chr_file permissive=0 With and without sudo makes no difference, as does adding --selinux-enabled. The main docker daemon does have selinux enabled. "docker run" and "docker start" both work fine with -t (and, in fact, the session I'm trying to exec in is started with -t). Disabling selinux enforcement with "setenforce 0" "fixes" the problem.
yum reinstall docker-selinux
Fixed it, thanks.
Hmmm... Ran into the same issue on the latest docker and docker-selinux, with the same fix. $ docker --version Docker version 1.8.2-fc22, build cb216be/1.8.2 @dwalsh: What happens that re-installing docker-selinux fixes?
Basically when the system was updated the update of docker-selinux failed. When you reinstall the update succeeds. The reason it is failing, is some of the packages that it required on install were not installed. selinux-policy-targeted for example.
Hmmmm... I've seen this happen a few times on my system and these are all the selinux related installed packages. $ rpm -qa | grep selinux libselinux-2.3-10.fc22.x86_64 libselinux-python-2.3-10.fc22.x86_64 libselinux-utils-2.3-10.fc22.x86_64 selinux-policy-targeted-3.13.1-128.21.fc22.noarch selinux-policy-3.13.1-128.21.fc22.noarch libselinux-ruby-2.3-10.fc22.x86_64 libselinux-python3-2.3-10.fc22.x86_64 selinux-policy-devel-3.13.1-128.21.fc22.noarch rpm-plugin-selinux-4.12.0.1-14.fc22.x86_64 selinux-policy-doc-3.13.1-128.21.fc22.noarch libselinux-devel-2.3-10.fc22.x86_64 docker-selinux-1.8.2-7.gitcb216be.fc22.x86_64 libselinux-2.3-10.fc22.i686 Would not the failure of dnf or yum update be noticed? I'll keep an eye out for that in the future, I suppose.
Yes you should see something in the logs. I would figure this would only happen once. One potential problem would be if selinux-policy-targeted is still shipping a docker.pp file, this could overwrite the docker.pp file provided in docker-selinux. This could mean that an selinux-policy-targeted update would remove the docker-selinux policy. rpm -ql selinux-policy-targeted | grep docker
Indeed. That appears to be what's happening: $ rpm -qil selinux-policy-targeted|grep docker /etc/selinux/targeted/modules/active/modules/docker.pp Which would explain why this crops up from time to time.
Please open a bug on Fedora 22 selinux-policy-targeted to remove the docker.pp I believe this is not an issue with 23 and Rawhide.
For anyone else who comes here and sees this thread. I opened this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1287245