Re: [RFR] templates://publicfile-installer/{templates}
Christian PERRIER wrote:
> Quoting Justin B Rye (justin.byam.rye@gmail.com):
>
>> But why does it need a special script to install a package? (Goes and
>> looks...) Yipe! It just checks I'm root and then runs
>>
>> dpkg -i /tmp/publicfile-installer/publicfile*_*.deb
>>
>> Does the build really leave its output in a predictable location in a
>> world-writable directory? (Checks) Yes, so if my evil kid brother
>> has created a /tmp/publicfile-installer/publicfile_0.52-0_amd64.deb,
>> the build-script will happily dump its .deb alongside it. Then when I
>> run "sudo install-publicfile" it'll install the bogus package first,
>> executing its install-scripts as root.
>
> That seems correct and probably deserves another bug report, in my
> opinion. Thanks for pointing this, Justin...
Unfortunately, fixing it probably requires changes to the visible
behaviour of the scripts that would mean changes to these debconf
prompts, so we'll need to put this review on hold.
I'm sending the bug to the security team (CCing the maintainer) rather
than the BTS in the hope that nobody reads d-l-e and we can call this
an undisclosed exploit.
Meanwhile, when I look for a fix I keep banging my head on further
bugs. For a start, how are manual unprivileged fakeroot builds
supposed to happen in /usr/src/publicfile-installer/, where I don't
have write access? Yes, it'll use $HOME/.publicfile-installer/ if
I've created it, but the instructions don't mention that stage. This
looks like more work to do in the debconf prompts.
And if the current $BUILDDIR might not be the same as the previous
$BUILDDIR, before it launches the build it really ought to ask dpkg
whether publicfile is already installed, and if so, at what version.
Just looking for a .deb lying around nearby isn't enough.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: