Comment 22 for bug 1642386

Revision history for this message
Julian Andres Klode (juliank) wrote :

Ah, apt-key explains it. We did not catch that in the bisect correctly, as I forgot to specify -o Dir::Bin::apt-key=$PWD/build/bin/apt-key :/

This means it is a regression introduced in:

commit b515fe3a0012c1f155dbf6a4199e919fec102578
Author: David Kalnischkies <email address hidden>
Date: Thu Jun 2 11:12:39 2016 +0200

    apt-key: change to / before find to satisfy its CWD needs

    First seen on hurd, but easily reproducible on all systems by removing
    the 'execution' bit from the current working directory and watching some
    tests (mostly the no-output expecting tests) fail due to find printing:
    "find: Failed to restore initial working directory: …"

    Samuel Thibault says in the bugreport:
    | To do its work, find first records the $PWD, then goes to
    | /etc/apt/trusted.gpg.d/ to find the files, and then goes back to $PWD.
    |
    | On Linux, getting $PWD from the 700 directory happens to work by luck
    | (POSIX says that getcwd can return [EACCES]: Search permission was denied
    | for the current directory, or read or search permission was denied for a
    | directory above the current directory in the file hierarchy). And going
    | back to $PWD fails, and thus find returns 1, but at least it emitted its
    | output.
    |
    | On Hurd, getting $PWD from the 700 directory fails, and find thus aborts
    | immediately, without emitting any output, and thus no keyring is found.
    |
    | So, to summarize, the issue is that since apt-get update runs find as a
    | non-root user, running it from a 700 directory breaks find.

    Solved as suggested by changing to '/' before running find, with some
    paranoia extra care taking to ensure the paths we give to find are really
    absolute paths first (they really should, but TMPDIR=. or a similar
    Dir::Etc::trustedparts setting could exist somewhere in the wild).

    The commit takes also the opportunity to make these lines slightly less
    error ignoring and the two find calls using (mostly) the same parameters.

    Thanks: Samuel Thibault for 'finding' the culprit!
    Closes: 826043
    (cherry picked from commit 0cfec3ab589c6309bf284438d2148c7742cdaf10)