On Sun, 2020-03-15 at 18:20 +0000, jnqnfe@gmail.com wrote: > 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. Great, thanks for fixing that - just wanted to ensure all details were in the bug report -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part