Re: Bug#826043: apt: gpg validation fails on hurd
Samuel Thibault, on Thu 02 Jun 2016 00:15:11 +0200, wrote:
> More precisely, running it from a directory which has perms 700 gets the
> issue.
Ok, I see the issue. What happens is that nowadays apt uses an _apt
user to do some operations, and notably running
find -L /etc/apt/trusted.gpg.d/ -type f -name *.gpg
from the cmdline/apt-key.in script.
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.
I guess it may make sense for apt to chdir to e.g. / before running the
find command, so that we are sure that find doesn't get any issue?
Actually it's pure luck that the script doesn't completely fail on Linux
when find fails due to not being able to restore the cwd: since the find
command is only used as parameter of a for loop, the returned value
is ignored by sh. Had the find command output been first stored in a
variable, the script would have aborted...
Samuel
Reply to: