Bug#953957: [live-build] W: Download is performed unsandboxed as root as file '<file>.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

[jnqnfe@gmail.com]

On Sun, 2020-03-15 at 11:34 +0000, Luca Boccassi wrote:
> The reason I asked for the change and I wasn't comfortable with
> making
> the download directory 777 is that live-build is routinely used in
> automated production systems to create images. I do not want to
> introduce the risk of a rogue, unprivileged process to be able to
> mess
> with the downloaded files after apt has ran, if it's just to fix a
> harmless warning.
> 
> If it can be fixed without introducing risk - great! If not, I would
> recommend to document it and leave it.

I hope that my bug report did not make you feel that I was being
critical of your decision. That is not the case, I very much agree with
whying away from 777. I was just trying to document the details of what
worked and what did not. :)

FWIW I care greatly about security and as mentioned in the MR, I need
to refresh my mind (I'll  look it up shortly) as to what protections
parent directory permissions give to subdirs as I might have been
mistakenly thinking that the parent having root:root 755 permissions
would prevent malicious outside access to this directory, but I'm
probably wrong. (a long time since I last referenced that fundamental
detail).

I'm not so sure that we could consider the warning harmless. I would
expect that apt is warning that it was unable to drop root privileges
to do verification of the file or something, which means that a
malicious file from a MITM hijack could trigger a bug if there were one
in apt and gain root privileges rather than user.

Anyway, I'm getting a little off topic...

---

Regarding the bug itself, I had an epiphany last night which I just
checked out and confirmed. The problem is simply that we're performing
the chown from the host level whilst running apt-get within the chroot,
and there's no guarantee that the _apt user will have the same UID
between the two. To fix the problem all we need to do is run chown
within the chroot environment too, thus actually assigning the correct
UID to the folder.

I just tested this and it works :D
I'll post an MR in a moment.