[pid 102267] setgroups(1, [0] <unfinished ...> [pid 102267] <... setgroups resumed>) = 0 ... [pid 102267] setresgid(65534, 65534, 65534) = 0 [pid 102267] setresuid(42, 42, 42) = 0 [pid 102267] getgid() = 65534 [pid 102267] getegid() = 65534 [pid 102267] getuid() = 42 [pid 102267] geteuid() = 42 [pid 102267] getresuid([42], [42], [42]) = 0 [pid 102267] write(1, "400 URI Failure\nMessage: Could n"..., 76) = 7642 and 65534 are in fact the uid and gid of the _apt user, according to pbuilder/sid-sparc64.cow/etc/passwd . Maybe it expects something else instead? But why it call setresuid(_apt, _apt, _apt) then...
Looking at the apt source code now...
This does not fail:
https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/contrib/fileutl.cc#L3353
if (geteuid() != pw->pw_uid)
return _error->Error("Could not switch effective user");
Further below, there's the reported error:
https://salsa.debian.org/apt-team/apt/-/blob/main/apt-pkg/contrib/fileutl.cc#L3361
if (getresuid(&ruid, &euid, &suid))
return _error->Errno("getresuid", "Could not get saved set-user-ID");
if (suid != pw->pw_uid)
return _error->Error("Could not switch saved set-user-ID");
This matches what we see in the strace output.
But here's is where it gets murky:
geteuid() returns 42, which is compared with pw->pw_uid, and since
there's no error here, I conclude that pw->pw_uid must be 42 at this point.
Then, getresuid() queries the saved-uid, and according to strace, it's also returned as 42. As long as nothing has changed pw->pw_uid in the meantime, the following comparison shouldn't fail.
pw_uid comes from a getpwnam() call further up, by the way, which appears in strace as reading from /etc/passwd. (not shown here, the whole trace is a bit too long)
I don't see any other option than to run this through a debugger, but that's a bit of a daunting task. Do you have any hints on how to proceed, or does this look familiar somehow?