Bug#936060: rocksndiamonds lintian override for maintainer-script-should-not-use-recursive-chown-or-chmod reasoning is incorrect

[Daniel Kahn Gillmor]

Hi Stephen--

On Thu 2019-08-29 23:18:53 +0200, Stephen Kitt wrote:

> Thanks for taking an interest in this, I’ve often wondered if I’d got my
> analysis right...

thanks for taking another look at this with me.

> But all this happens inside $tempdir, which is root:root 700. If anyone can
> race there, or read files, we’ve lost already, haven’t we? And if they can’t,
> then we’re safe, at least until we copy the files elsewhere — and I think at
> this point we’re sure the files can only match the contents of the archives we
> unpack.

ok, that's certainly an improved argument for why it doesn't matter as
much, compared to the lintian-override :)

But from a defense in depth scenario, it'd still be much nicer to not
worry about this stuff happening at all :/  For example, what if there
is a bug in the network fetching or archive extraction tools?

> The scenario I was thinking of when I wrote my comment was the issue of
> suid/sgid binaries, since those could be stored in the archives we extract.
> But even then, I don’t think there would be a way of exploiting them even if
> the chown happened before the chmods, and in any case the archives are
> extracted without preserving permissions...

Is there a reason that the archives need to be fetched and extracted as
the superuser in the first place?  if all that work was done by a
non-privileged user, then there'd be no chance of the files being
suid/sgid even if there was a heinous bug in the extractor, because the
kernel wouldn't let that happen.

Then you could ignore the chown, and just ensure that the files are
world-readable in the normal way.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20190830/4482756c/attachment.sig>