Red Hat Bugzilla – Bug 1293357
sudo not functional in a container - device not a stream
Last modified: 2016-01-25 07:47:47 EST
Description of problem: When attempting to use sudo in a Docker container, the following error is thrown: [kitchen@602b5f07bec4 ~]$ /usr/bin/sudo ls -al -bash: /usr/bin/sudo: Device not a stream The container is built and run as part of an automated process, and sudo is configured to not require a tty from that process. Further if root runs any sudo command, then any subsequent sudo commands from any other user work normally - however since this is part of an automated process, customer cannot accept that workaround. Full details of the automated process under additional info. Version-Release number of selected component (if applicable): rhel-7.2 kernel-3.10.0-327.el7.x86_64 docker-1.8.2-8.el7.x86_64 How reproducible: Always for customer following build, I have not been able to reproduce this. Steps to Reproduce: 1. 2. 3. Actual results: sudo, if run from as any user except root will give a "device not a stream" error. After root runs sudo, all sudo commands work normally. Expected results: sudo should function normally without having to use root first. Additional info: Following is a braindump from the customer on how these containers are built and run: *************** BEGIN *************** Background: At Raymond James we use Chef for configuration management. Chef has a feature called test-kitchen that helps us functionally test chef cookbooks during our development and continuous integration process. We are using Docker for only testing chef cookbooks. Docker is not used in any other environment. Test-kitchen uses a gem called “kitchen-docker” to interface with the Docker subsystem to run containers and apply chef constructs and run tests. This is all controlled through a .kitchen.yml. We have Test-Kitchen working with Docker with Centos7 with no issues. How we build our primary image? We use the following docker file to build our primary image. In this example lets call it “test-chef2”. We build an image called “test-chef2” and we tag and push it to our internal registry. FYI- chef’s test-kitchen uses ssh/scp to push files to the container for testing. Also, we test chef cookbooks that use systemd because we install components that run as services. Again, we are not running Docker in upper environments and this implementation is used only test within a shor-tlived container ( lifespan – a few minutes). ################ start of Dockerfile use for our base image ################ FROM registry.access.redhat.com/rhel7 MAINTAINER <removed> RUN yum swap -y fakesystemd systemd RUN yum install -y initscripts CMD ["/sbin/init", "3"] RUN yum install -y openssh-server openssh-clients sudo net-tools RUN yum -y install crontabs curl initscripts net-tools passwd sudo tar which && \ (curl -L https://www.opscode.com/chef/install.sh | bash -s — -v 12.0.3) ############################################### How kitchen-docker works? Chef’s test-kitchen needs to ensure it can ssh/scp into the container ( we know that this is not normal, but chef needs to do this as part of its testing process). The .kitchen.yml file has settings that instructs kitchen-docker and test-kitchen on what to build and how to start containers. See the .kitchen.yml settings below. Notice how the image is set to “test-chef2”. Also notice we are running “unprivileged” and calling /sbin/init as our start command. platforms: - name: rhel driver_config: image: test-chef2 privileged: true platform: "rhel" run_command: /sbin/init; sleep 5 When test kitchen runs it does the following: 1. Under the covers it creates a temporary Dockerfile and uses “From test-chef2” as its base image 2. The temporary docker file adds a user called “kitchen” and gives it sudo capabilities. The sudo requirement comes from chef and test-kitchen. During the test-kitchen process, a chef-client is installed, a lightweight server called chef-zero is installed as well as all cookbooks and non chef cookbook constructs are created. As part of these installs and executions sudo is required. This is basis of this fully functioning widely used implementation. ( I have provided the temporary docker file contents below) 3. Test-kitchen creates a temporary new image from the temporary docker-file 4. Test-kitchen then runs a container from the temporary image. 1. Maps a high port for ssh 2. Provides docker run switches, etc 5. After the container is started, 1. Test-kitchen scps constructs to the container 2. It then installs and executes tasks as sudo ============ output of a test-kitchen run ============ docker -H tcp://192.168.59.103:2376 run -d -p 22 --privileged 5747915be2b8 /sbin/init; sleep 5 The following is port mapping docker -H tcp://192.168.59.103:2376 port bcaee299d487f531f25da77f4abf77b6efe9897cc71ab1573e3be85d437b77ad 22/tcp And the following high port is what is returned and then used by test-kitchen for scp/ssh 32808 ======================================== ########################################### start of temporary Dockerfile created and used by test-kitchen ########################## Step 0 : FROM test-chef2 Step 1 : RUN yum clean all Step 2 : RUN yum install -y sudo openssh-server openssh-clients which curl Step 3 : RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N '' Step 4 : RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N '' Step 5 : RUN if ! getent passwd kitchen; then useradd -d /home/kitchen -m -s /bin/bash kitchen; fi Step 6 : RUN echo kitchen:kitchen | chpasswd Step 7 : RUN echo 'kitchen ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers Step 8 : RUN mkdir -p /etc/sudoers.d Step 9 : RUN echo 'kitchen ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/kitchen Step 10 : RUN chmod 0440 /etc/sudoers.d/kitchen Step 11 : RUN [ ! -d /home/kitchen/.ssh ] && mkdir /home/kitchen/.ssh Step 12 : RUN chown -R kitchen /home/kitchen/.ssh Step 13 : RUN chmod 0700 /home/kitchen/.ssh Step 14 : RUN echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDE4DgiBr6Tjt6pwX8VRiaedbdDOFw4sBxMzgI7t0X2gl2E3lto+AjxbgEo0iNSXast+eo0d2hhs75nwu+kU5PdOJ6Mz5hAdOF9Q7WfW2tkD1w2Cgf/xZTQFWMbLYo3a2UY/n9dmTpxxdCe6/U2LZGCVTBfBzPujsdPbMmmKZnuX9OPY4vxsuuafrdKR7jb74wxi9507xkwU6wvS7od/qLAHXZk7rfL2JWdCrzIT/6/9BrElRKD+btZQwzkc/ZXnn7MvAoUls7uIeSAM+Xx0KbYN1GThPwEXDTmPrXwnqGg4S8FBbNa5ohc4PRxOubeoIujIxxRyLK9bOTu3p61oxL7 kitchen_docker_key' >> /home/kitchen/.ssh/authorized_keys Step 15 : RUN chown kitchen /home/kitchen/.ssh/authorized_keys Step 16 : RUN chmod 0600 /home/kitchen/.ssh/authorized_keys Successfully built a4790107336f 56b3f6c9667ac66b1dd4fe84a464da0f03beb45df3fe17b29056093bf2d9743e 0.0.0.0:32775 [SSH] Established Finished creating <default-rhel> (0m11.41s). ############################################################################################################ *************** END ***************
Antonio can you take a look at this?
Customer just updated us saying that they found this to be a problem caused by Sophos AV. The Sophos logs would show that it tried to block to initial sudo command, which seemed to work however the logs indicated a Sophos-side problem with namespacing, and thus never tried to block the following sudo commands. I think we can close this as NOTABUG.