[Bug 1916485] Re: test -x fails inside shell scripts in containers

Tue Apr 20 10:43:05 UTC 2021

Guest is Hirsute to have
  libc6:s390x    2.33-0ubuntu5 s390x

The following (not optimized for speed but readability) gives us a
simple environment-matrix for comparisons:

for r in xenial bionic focal groovy hirsute; do
    uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=s390x label=daily release=${r};
    uvt-kvm create --host-passthrough --password=ubuntu ${r}-test-nspawn release=${r} arch=s390x label=daily;
    uvt-kvm wait ${r}-test-nspawn
    uvt-kvm ssh ${r}-test-nspawn "sudo apt update"
    uvt-kvm ssh ${r}-test-nspawn "sudo apt upgrade -y"
    uvt-kvm ssh ${r}-test-nspawn "wget https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-s390x-root.tar.xz"
    uvt-kvm ssh ${r}-test-nspawn "mkdir h"
    uvt-kvm ssh ${r}-test-nspawn "sudo tar -xzf hirsute-server-cloudimg-s390x-root.tar.xz -C h";
    uvt-kvm ssh ${r}-test-nspawn "sudo apt install -y systemd-container"
    uvt-kvm ssh ${r}-test-nspawn "sudo reboot";
    sleep 5s
    uvt-kvm wait ${r}-test-nspawn
done

Test (as before) is:
$ cd h
$ sudo systemd-nspawn
$ bash -c 'test -x /usr/bin/gpg || echo Fail'

Out of that I can confirm (and further limit releases to just bionic) that on s390x we have:
Xenial - 4.4.0-210/229-4ubuntu21.31 - works
Bionic - 4.15.0-142/237-3ubuntu10.46 - fails
Focal - 5.4.0-72/245.4-4ubuntu3.6 - works
Groovy - 5.8.0-50/246.6-1ubuntu1.3 - works
Hirsute - 5.11.0-16/247.3-3ubuntu3 - works

Next I split the Bionic case to for a few usual suspects (kernel/systemd/glibc):
Already on step #1 Kernel I found something:
Bionic - 4.15.0-142/237-3ubuntu10.46 - fails
Bionic - 5.4.0-72/237-3ubuntu10.46 - works

Ok so the new kernel fixes it (whatever it is) so what about things in proposed already:
There is a new 4.15 kernel and a new systemd
Bionic - 4.15.0-143/237-3ubuntu10.47 - fails

So none of the builds in proposed has the fix, but something between
4.15 and 5.4 kernels fixes it. That might also be the reason why the
other releases are fine - the kernel levels are either >=5.4 (fixed) or
<4.15 (not having the issue).

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1916485

Title:
  test -x fails inside shell scripts in containers

Status in docker.io package in Ubuntu:
  New
Status in glibc package in Ubuntu:
  Opinion
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in runc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in docker.io source package in Xenial:
  New
Status in libseccomp source package in Xenial:
  New
Status in runc source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in docker.io source package in Bionic:
  New
Status in libseccomp source package in Bionic:
  New
Status in runc source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in docker.io source package in Focal:
  New
Status in libseccomp source package in Focal:
  New
Status in runc source package in Focal:
  Fix Released
Status in systemd source package in Focal:
  Fix Released
Status in docker.io source package in Groovy:
  New
Status in libseccomp source package in Groovy:
  New
Status in runc source package in Groovy:
  Fix Released
Status in systemd source package in Groovy:
  Fix Released
Status in docker.io source package in Hirsute:
  New
Status in libseccomp source package in Hirsute:
  Fix Committed
Status in runc source package in Hirsute:
  Fix Released
Status in systemd source package in Hirsute:
  Fix Released
Status in systemd package in Debian:
  Fix Released

Bug description:
  (SRU template for systemd)

  [impact]

  bash (and some other shells) builtin test command -x operation fails

  [test case]

  on any affected host system, start nspawn container, e.g.:

  $ sudo apt install systemd-container
  $ wget https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz
  $ mkdir h
  $ cd h
  $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz
  $ sudo systemd-nspawn

  Then from a bash shell, verify if test -x works:

  root at h:~# ls -l /usr/bin/gpg
  -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg
  root at h:~# test -x /usr/bin/gpg || echo "fail"
  fail

  [regression potential]

  any regression would likely occur during a syscall, most likely
  faccessat2(), or during other syscalls.

  [scope]

  this is needed for b/f

  this is fixed upstream by commit
  bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so
  this is fixed in h

  this was pulled into Debian at version 246.2 in commit
  e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g

  in x, the entire systemd seccomp code is completely different and the
  patch doesn't apply, nor does it appear to be needed, as the problem
  doesn't reproduce in a h container under x.

  [other info]

  this needs fixing in libseccomp as well

  [original description]

  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root at 0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root at 0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root at 0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root at 0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root at 0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root at 0df2ce5d7a46:/#

  root at 0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root at 0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root at 0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root at 0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root at 84b750e443f8:/# lsb_release -rd
  Description:	Ubuntu Hirsute Hippo (development branch)
  Release:	21.04
  root at 84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name           Version         Architecture Description
  +++-==============-===============-============-==========================================
  ii  apt            2.1.20          amd64        commandline package manager
  ii  gnupg          2.2.20-1ubuntu2 all          GNU privacy guard - a free PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of
  them is required for this operation

  The simple Dockerfile to reproduce the error - "docker build -t foo ."

  FROM amd64/ubuntu:hirsute
  MAINTAINER Florian Lohoff <f at zz.de>

  USER root

  RUN apt-get update \
   && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \
    && curl https://syncthing.net/release-key.txt | apt-key add -

  Breaking it down it this seems to be an issue that there is new
  functionality in apt/apt-key e.g. security hardening that docker
  prohibits in its containers. Running this manually works only in an
  --privileged container.

  So adding keys in unpriviledged container or possibly kubernetes will
  not work anymore.

  Flo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1916485/+subscriptions