Hi, Quoting Antoine Beaupré (2024-12-29 16:52:26) > > This also reminds me of #1089105 which comes down to zstd not accepting > > compressed data on stdin and writing the uncompressed result to stdout > > without also passing --force. Seems entirely unintuitive to me... > > Is it worth filing this against zstd and affecting sbuild maybe?
this is not the hill I want to die upon. But feel free to make an argument with
the developers.
> > Thank you for having found this. Maybe we should just call zstd with
> > '--force' and call it a dway...
>
> That seems dangerous in many ways: zstd setup this thing which sounds to
> me like a security feature, albeit poorly documented...
>
> If I read this right, there's even a TOCTOU bug in there, because we're
> checking symlinks before use, and and an attacker could replace a file
> with a symlink later. Anyway.
>
> Not sure what to do about this, I think the best might possibly be to move
> this to the zstd package...
I found a different solution. I was wondering how GNU tar does it and perused
its source code a bit. And then I just copied their solution. :)
If you like, can you try this patch:
--- /usr/share/perl5/Sbuild/ChrootUnshare.pm
+++ /usr/share/perl5/Sbuild/ChrootUnshare.pm
@@ -533,14 +533,15 @@ sub begin_session {
my $pid_decompress = fork();
if ($pid_decompress == 0) {
open(STDOUT, '>&', $decompress_writer);
+ open(STDIN, '<', $tarball);
close $filter_reader;
close $tar_reader;
close $filter_writer;
if ($self->get_conf('DEBUG')) {
printf STDERR (
- "running $decompress[0] --decompress --stdout $tarball\n");
+ "running $decompress[0] --decompress --stdout\n");
}
- exec @decompress, $tarball;
+ exec @decompress;
}
my $pid_filter = fork();
if ($pid_filter == 0) {
Essentially, we do not pass a path to zstd anymore but we let sbuild open the
path and then pass the filedescriptor to what we opened to zstd via its
standard input.
Thanks!
cheers, josch
signature.asc
Description: signature
