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 ***************