On Tue, Apr 16, 2024 at 03:54:41PM -0600, Todd C. Miller wrote:
> On Tue, 16 Apr 2024 23:39:50 +0200, Jeremie Courreges-Anglas wrote:
>
> > Here's a cheap trick. Testing with path=... longer than PATH_MAX
> > results in broken behavior. If you want to test this with symbolic
> > links and long linkpath=... please use the latest tar.c.
> >
> > There's probably a better way to solve this but the amount of pointer
> > arithmetic in this function doesn't make it attractive. What do you
> > folks think?
>
> I think this is fine, we don't need to support paths larger than
> PATH_MAX. With this diff MAXXHDRSZ is now unused and can be removed
> from tar.c.
Indeed, spotted too late, thanks. But maybe the latter looks, ahem, nicer?
The name and ln_name buffers are sized using it.
Index: tar.c
===================================================================
--- tar.c.orig 2024-04-16 22:29:44.269086676 +0100
+++ tar.c 2024-04-16 22:56:19.659174496 +0100
@@ -62,9 +62,6 @@
/* shortest possible extended record: "5 a=\n" */
#define MINXHDRSZ 5
-/* longest record we'll accept */
-#define MAXXHDRSZ BLKMULT
-
/*
* Routines for reading, writing and header identify of various versions of tar
*/
@@ -1588,7 +1585,11 @@
static int
rd_xheader(ARCHD *arcn, int global, off_t size)
{
- char buf[MAXXHDRSZ];
+ /*
+ * The pax format supposedly supports arbitrarily sized extended
+ * record headers, this implementation doesn't.
+ */
+ char buf[sizeof("30xx linkpath=") - 1 + PAXPATHLEN + sizeof("\n")];
long len;
char *delim, *keyword;
char *nextp, *p, *end;
--
jca
