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

[Stephen Kitt]

Hi Daniel,

On Fri, 30 Aug 2019 00:47:51 -0400, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Thu 2019-08-29 23:18:53 +0200, Stephen Kitt wrote:
[...]
> > 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.

No reason at all, and using a non-privileged user would be much better, and
not particularly hard to implement.

For Bullseye I’d like to replace all this with game-data-packager, but that
will take a bit longer...

Regards,

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20190830/307a423c/attachment.sig>