[Bug 2059734] Re: Tar fails to extract archives that include folders with certain permissions on armhf

Wed Jun 19 13:04:17 UTC 2024

Are we sure this issue doesn't affect 24.04? This bug was filed on 27
March, a day after libseccomp 2.5.5-1ubuntu1 was published into the
Noble release pocket. It looks like this was first fixed upstream in
2.5.5. The original reporter (understandably) did not report the version
of the libseccomp package used. After fixing the Test Plan as I've
requested below, please run that against 24.04 to make sure, and report
the results.

Presumably this bug isn't currently fixed in 23.10 since 2.5.4-1ubuntu3
is current there. This is a prerequisite to fixing 22.04. Please see
https://wiki.ubuntu.com/StableReleaseUpdates#Newer_Releases.

> On an ARM 64 machine install the latest version of docker on a jammy
host by following the official docker documentation.
[https://docs.docker.com/engine/install/ubuntu/]

Please update the Test Plan to use Docker as shipped by Ubuntu. Or, if
this issue only affects a version of Docker external to the Ubuntu
archive, then we might still be able to fix libseccomp for you, but it
changes the calculus considerably. Please document the specifics, and
tie it to a specific version that has specific behaviour (what,
exactly?) rather than the moving target of "latest".

> However docker seccomp profile defaults to returning EPERM for all non
defined syscalls and writing an entry for fchmodat2 in the docker
seccomp profile to return ENOSYS does not work on systems where
libseccomp does not have support for fchmodat2.

Will libseccomp allow Docker to return ENOSYS for all non defined
syscalls instead? This seems like it would be the correct general fix to
me, to avoid future breakages of the same class. Is this possible, and
how would doing this instead change the risk to 22.04 in this fix? If
this issue only affects an upstream version of Docker, can that be fixed
there please, rather than risking regression to all other libseccomp
consumers by working around this in libseccomp in 22.04? Then I think
your "use the latest version of upstream Docker" would just start
working?

The proposed patch looks like it adds system call numbers for fchmodat2
for all architectures, as well as for a bunch of other system calls. The
architecture-specific changes seem to apply to cacheflush and
memfd_secret system calls only. So is this an armhf-specific problem, or
is it a general one that affects all architectures?

Following "the requirements for stable updates are not necessarily the
same as those in the development release" from
https://wiki.ubuntu.com/StableReleaseUpdates#Why, why is this SRU patch
not minimal, adding the definition for the required system call for the
affected architectures only?

Or, if the problem we're solving is wider than this and requires the
full patch, then I think we need to include that in our regression
analysis please, together with a Test Plan that exercises relevant code
paths.

In particular, I'm concerned that the proposed change will affect much
more than the bug being fixed, increasing regression risk including to
other consumers of libseccomp, and that these additional cases aren't
covered by the Test Plan. Many more system calls could suddenly "start
working" from the perspective of glibc, rather than returning EPERM,
depending on how libseccomp is being used. As well as changing behaviour
in undetermined ways, this could also have security implications.

I'd much prefer to see just the fchmodat2 syscall arranged to return
ENOSYS rather than EPERM, to meet glibc's expectations. This would seem
to be the minimalist safe fix to me. Is it possible to hack that in as a
magic number? If this isn't possible, then I'd like to see a
documentation as to why, please, including for example why Docker cannot
arrange ENOSYS for all unknown system calls. And if that's not possible,
then can we just touch fchmodat2 in libseccomp in 22.04, rather than
messing with other system calls as well?

Sorry I can't give you a specific set of things that I want to see yet -
it depends on answers to my various questions above. I'm also sure that
there are gaps in my understanding - feel free to fill those in. The key
thing is that this is all documented please, such that it is made clear
to someone unfamiliar with the specifics why a wide-reaching change is
necessary and why a more minimal fix is not possible.

** Changed in: libseccomp (Ubuntu Jammy)
       Status: In Progress => Incomplete

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

Title:
  Tar fails to extract archives that include folders with certain
  permissions on armhf

Status in libseccomp package in Ubuntu:
  Fix Released
Status in tar package in Ubuntu:
  Invalid
Status in libseccomp source package in Jammy:
  Incomplete

Bug description:
  Thank you @loganbussell-msft for the bug report!

  [Impact]

  Currently running containers using modern versions of glibc such as
  the one available in noble on older hosts causes permissions issues
  inside the container. This is due to newer versions of glibc expecting
  the fchmodat2 syscall to be available and to return ENOSYS in case it
  is not. However docker seccomp profile defaults to returning EPERM for
  all non defined syscalls and writing an entry for fchmodat2 in the
  docker seccomp profile to return ENOSYS does not work on systems where
  libseccomp does not have support for fchmodat2.

  Running armhf noble docker containers on arm64 jammy hosts has been
  seen to exhibit this behavior and a patch to libseccomp for jammy is
  required to fix the issue.

  Other architectures may also be affected by this issue that such as
  ppc64le as reported by @mark-elvers.

  I have backported a fix from upstream that adds the missing syscalls
  to libseccomp and verified it on an ampere arm machine as well as on a
  raspberry pi 4

  [Test Plan]

  1- On an ARM 64 machine install the latest version of docker on a
  jammy host by following the official docker documentation.
  [https://docs.docker.com/engine/install/ubuntu/]

  2- Create an armhf noble docker container:
  $ docker run --rm -it --platform linux/arm/v7 --entrypoint bash ubuntu.azurecr.io/ubuntu:noble

  3- inside the docker container execute the following commands to
  create a new tar file and then extract it:

  mkdir /test \
      && chmod 775 /test \
      && cd /test \
      && mkdir 775 \
      && chmod 775 775 \
      && touch 775/test.txt \
      && chmod 644 775/test.txt \
      && tar -czvf /test.tar.gz .

  mkdir -p /test2 \
      && tar -tzvf /test.tar.gz \
      && tar -oxzf /test.tar.gz -C /test2

  4- you will see the following errors:

  tar: ./775: Cannot change mode to rwxrwxr-x: Operation not permitted
  tar: Exiting with failure status due to previous errors

  5- When  libseccomp is patched the command will run with no permission
  issues

  [Where problems could occur]

  * the issue might still occur on other platforms 
  * if using an older version of docker the issue will still occur

  [Original Description]
  When running Ubuntu Noble in an arm32 Docker container, on certain hosts (Azure VM CI agents), tar fails to extract certain archives that include folders with specific permissions set.

  Here's a concise repro. The error occurs in when building the
  Dockerfile. I can only get this to work on Azure VMs, but can't find
  out why.

  ```Dockerfile
  FROM ubuntu.azurecr.io/ubuntu:noble

  # Create the problematic archive
  RUN mkdir /test \
      && chmod 775 /test \
      && cd /test \
      && mkdir 775 \
      && chmod 775 775 \
      && touch 775/test.txt \
      && chmod 644 775/test.txt \
      && tar -czvf /test.tar.gz .

  # Extracting it gives an error
  RUN mkdir -p /test2 \
      && tar -tzvf /test.tar.gz \
      && tar -oxzf /test.tar.gz -C /test2
  ```

  What I expected to happen: The test.tar.gz archive should be
  successfully extracted to the /test2 directory.

  What happened instead: Tar throws the following error:
  ```
  tar: ./775: Cannot change mode to rwxrwxr-x: Operation not permitted
  tar: Exiting with failure status due to previous errors
  ```

  The Ubuntu container is running as root so there shouldn't be any
  permission errors.

  Since this is running in a container, I observed this happening on the following kernel:
  `Linux version 5.15.148.2-2.cm2 (root at CBL-Mariner) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Feb 23 23:38:33 UTC 2024`
  As well as
  `Linux <hostname> 6.5.0-1017-azure #17~22.04.1-Ubuntu SMP Sat Mar  9 10:04:07 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux`

  I was not able to reproduce it using Ubuntu 22.04 Jammy
  (ubuntu.azurecr.io/ubuntu:jammy), using the same kernel as above.

  Additionally I was not able to reproduce this on the kernel `Linux
  cb0507859b24 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11
  04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux`, which is running on
  my work machine, using Docker qemu emulation for the arm32 image.

  Ubuntu version: Ubuntu Noble Numbat (development branch) 24.04 (from ubuntu.azurecr.io/ubuntu:noble)
  tar version: `1.35+dfsg-3`

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/2059734/+subscriptions