Bug#910985: tar: Only encode known mode bits in oldgnu format
Package: tar
Version: 1.30+dfsg-2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: debian-hurd@lists.debian.org, debian-dpkg@lists.debian.org
Hi!
This is the original mail I sent to debian-hurd@l.d.o:
On Fri, 2018-09-28 at 09:59:57 +0200, Guillem Jover wrote:
> I was checking the dpkg 1.19.1 FTBFS on the Hurd, and noticed few
> things:
>
> * GNU tar with -Holdgnu seems broken (?) when packing a fifo, as it
> stores at least the S_IROOT mode bit, which makes GNU tar encode
> the mode data in base-256 (dpkg suppports that just fine, but it's
> still unexpected, and seems incorrect to me). None of the other tar
> formats show this behavior.
> * None of the other dpkg tests fail except for this one.
> * dpkg is now being built w/o fakeroot due to the R³ field set to no.
> * Building the source with fakeroot again makes GNU tar with -Holdgnu
> not store said bit, so it's a possible workaround for a dpkg porter
> build, probably.
>
> So while I could workaround this in the test suite, I think it'd be
> better to investigate why GNU tar behaves this way, and possibly fix
> it there.
I've now sat down, and skimmed over the GNU tar code doing the mode
encoding, and noticed the obvious omission of oldgnu there. Attached
a patch for tar which when built on GNU/Hurd, makes the dpkg test
suite pass again.
I've not checked the fakeroot code, but I'm expecting it's just
masking the high mode bits in one of its interposing libc calls.
I started running the tar test suite on GNU/Linux but that was using
too much space which I currently do not have, so I stopped it and have
not run it on either GNU/Linux nor GNU/Hurd. While the fix seems rather
obvious to me, I'd appreciate if someone with more beefy GNU/Linux and
GNU/Hurd systems could run the test suite, please?
Thanks,
Guillem
Description: Do not encode unknown mode bits with oldgnu format.
The oldgnu format can encode large header fields in base-256. On the Hurd,
for example, a fifo is a translator and its mode bits contain at least the
S_IROOT (040000000) bit set. For the v7 and ustar formats all unknown
mode bits are masked at the call site, and ustar, posix and gnu formats
only encode known mode bits. But oldgnu is left unmasked and encoding all
unknown bits, which is very unexpected as these are system-specific internal
details on how to represent fifos (or other translators).
.
GNU tar should consider oldgnu in the same way as the gnu, posix and ustar
formats, and ignore unknown bits when encoding the mode.
Author: Guillem Jover <guillem@debian.org>
Origin: vendor
Forwarded: no
Last-Update: 2018-10-14
---
--- tar-1.30+dfsg.orig/src/create.c
+++ tar-1.30+dfsg/src/create.c
@@ -384,7 +384,7 @@ static bool
mode_to_chars (mode_t v, char *p, size_t s)
{
/* In the common case where the internal and external mode bits are the same,
- and we are not using POSIX or GNU format,
+ and we are not using POSIX or GNU formats,
propagate all unknown bits to the external mode.
This matches historical practice.
Otherwise, just copy the bits we know about. */
@@ -396,6 +396,7 @@ mode_to_chars (mode_t v, char *p, size_t
&& S_IROTH == TOREAD && S_IWOTH == TOWRITE && S_IXOTH == TOEXEC
&& archive_format != POSIX_FORMAT
&& archive_format != USTAR_FORMAT
+ && archive_format != OLDGNU_FORMAT
&& archive_format != GNU_FORMAT)
{
negative = v < 0;
Reply to: