Bug#597672: rmt broken by the security fix in 1.20-1+lenny1 version of tar
On Wed, 22 Sep 2010 13:29:26 +1200, Dennis Vshivkov wal...@amur.ru wrote: According to the changelog, the latest version of tar package in lenny replaced rmt source with the one from paxutils for security reasons. Unfortunately, it also made it impossible to use tar and rmt together. Have you tried using a tar 1.23 version? The rmt version I used for 1.20-1+lenny1 is the one that's shipping in the current tar source tree. So, I'd like to understand whether there's something about fresher versions of tar that causes them to work better with rmt, or if this is a general upstream problem with the rmt in tar at this point. Bdale pgpEPt3GYj2Xi.pgp Description: PGP signature
Bug#597672: rmt broken by the security fix in 1.20-1+lenny1 version of tar
On Wed, Sep 22, 2010 at 12:15:47AM -0600, Bdale Garbee wrote: According to the changelog, the latest version of tar package in lenny replaced rmt source with the one from paxutils for security reasons. Unfortunately, it also made it impossible to use tar and rmt together. Have you tried using a tar 1.23 version? The rmt version I used for 1.20-1+lenny1 is the one that's shipping in the current tar source tree. So, I'd like to understand whether there's something about fresher versions of tar that causes them to work better with rmt, or if this is a general upstream problem with the rmt in tar at this point. I hadn't before. I have just tried using rmt binary from tar 1.23-2.1 (squeeze). It's just as broken as the one in 1.20-1+lenny1. Using it with tar binary from the same version of the package doesn't help either, naturally. My bad, I misinterpreted the 1.20-1+lenny1 changelog entry, somehow thinking that taking paxutils rmt was a Debian-specific way of the security fix. It indeed seems a tar upstream problem. However, I also found out that rmt in the paxutils upstream has been altered a week ago to fix the buffering of stdout (but not debug output) and parsing of the `mode' argument of `O' command. (I found that out from Debian bug #587702, reporting essentially the same as the one I posted, albeit with no patches. I should have found it first and added to it instead of posting a new report, another bad of mine...) So, Debian Lenny version of tar package can wait for the updated rmt to get from paxutils upstream to tar upstream, and then reimport it, or reimport the updated rmt directly from paxutils upstream, or just outright apply the fixes like mine or the one referred to in #587702. Cheers, -- /Awesome Walrus wal...@amur.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597672: rmt broken by the security fix in 1.20-1+lenny1 version of tar
On Wed, 22 Sep 2010 19:37:13 +1200, Dennis Vshivkov wal...@amur.ru wrote: However, I also found out that rmt in the paxutils upstream has been altered a week ago to fix the buffering of stdout (but not debug output) and parsing of the `mode' argument of `O' command. Yes, I noticed that after sending the email .. sigh. I've done an upload of tar to unstable with this and a couple other bug fixes, please give it a try if you can and let me know if it solves your problem. If it does, then I'll find time to patch the lenny version with the same fix to rmt. Bdale pgpMxOUqSHulg.pgp Description: PGP signature
Bug#597672: rmt broken by the security fix in 1.20-1+lenny1 version of tar
On Wed, Sep 22, 2010 at 03:26:50AM -0600, Bdale Garbee wrote: However, I also found out that rmt in the paxutils upstream has been altered a week ago to fix the buffering of stdout (but not debug output) and parsing of the `mode' argument of `O' command. Yes, I noticed that after sending the email .. sigh. I've done an upload of tar to unstable with this and a couple other bug fixes, please give it a try if you can and let me know if it solves your problem. If it does, then I'll find time to patch the lenny version with the same fix to rmt. I have just given rmt from your fresh tar 1.23-3 (unstable) a quick try, and can confirm that it seems to work with tar from the same and previous package versions, solving my problem just fine. It should be OK to patch the lenny version with the fix. Thanks, -- /Awesome Walrus wal...@amur.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597672: rmt broken by the security fix in 1.20-1+lenny1 version of tar
Package: tar
Version: 1.20-1+lenny1
Severity: important
Tag: patch
According to the changelog, the latest version of tar package in
lenny replaced rmt source with the one from paxutils for
security reasons. Unfortunately, it also made it impossible to
use tar and rmt together.
Here's what happens if one tries to tar to a remote file (ssh
plays the role of rsh, as is common nowadays):
$ tar cf localhost:foo.tar a-file
Password:
... hangs forever ...
Here's what the rmt binary is doing at the other end:
...
fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77f5000
read(0, Ofoo.tar\n65 O_WRONLY|O_CREAT\n..., 4096) = 29
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77f4000
read(0,
... hangs forever ...
So, rmt receives the O command from tar, does not respond and
expects more commands. And tar keeps awaiting the response to
the O command. Both hang indefinitely.
After looking at the new rmt source code, it is rather puzzling
how that rmt from paxutils could ever work. The problem is that
it uses stdio for its stdout, and by default that is block
buffered. Let's try fixing that for stdout, and to boot, for
the debug file output of the new rmt, that has the same problem:
--- tar-1.20/rmt/rmt.c 2010-09-22 12:12:15.0 +1200
+++ tar-1.20/rmt/rmt.c 2010-09-22 12:16:09.0 +1200
@@ -696,6 +696,7 @@ parse_opt (int key, char *arg, struct ar
dbgout = fopen (arg, w);
if (!dbgout)
error (EXIT_FAILURE, errno, _(cannot open %s), arg);
+ setlinebuf(dbgout);
break;
case ARGP_KEY_FINI:
@@ -745,6 +746,7 @@ main (int argc, char **argv)
int idx;
int stop = 0;
+ setlinebuf(stdout);
program_name = argv[0];
// argp_version_setup (rmt, rmt_authors);
That isn't enough, however:
$ tar cf localhost:foo.tar a-file
Password:
tar: localhost\:foo.tar: Cannot open: Invalid argument
tar: Error is not recoverable: exiting now
This further problem is now revealed by strace of the rmt side:
...
fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77bf000
read(0, Ofoo.tar\n65 O_WRONLY|O_CREAT\n..., 4096) = 29
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb77be000
write(1, E22\n..., 4) = 4
write(1, invalid open mode\n..., 18) = 18
read(0, ..., 4096) = 0
exit_group(0) = ?
The decode_open_flag() function in the rmt from paxutils can not
cope with the `65 O_WRONLY|O_CREAT' value of the `mode' argument
(as rmt(8) calls it) that tar emits. The coexistence of numeric
and symbolic flag values breaks it. More quick fixing:
--- tar-1.20/rmt/rmt.c 2010-09-22 12:12:15.0 +1200
+++ tar-1.20/rmt/rmt.c 2010-09-22 12:16:09.0 +1200
@@ -238,8 +238,14 @@ decode_open_flag (const char *mstr, int
if (*mstr == 0)
break;
else if (c_isdigit (*mstr))
- v = strtol (mstr, (char**) p, 10);
- else if (xlat_kw (mstr, O_, open_flag_kw, v, p))
+{
+ *pmode = strtol (mstr, (char**) mstr, 10);
+ if (*mstr !c_isblank (*mstr))
+ rmt_error_message (EINVAL, invalid open mode);
+ continue;
+ }
+
+ if (xlat_kw (mstr, O_, open_flag_kw, v, p))
{
rmt_error_message (EINVAL, invalid open mode);
return 1;
@@ -265,7 +271,8 @@ decode_open_flag (const char *mstr, int
return 1;
}
}
- *pmode = mode;
+ if (mode)
+*pmode = mode;
return 0;
}
Now my remote tar backups seem to work again, as they did with
tar 1.20-1 and earlier.
Whatever is best to do (applying fixes like the above to the rmt
from paxutils, properly porting the original security fix from a
safe version of tar upstream, or something yet different), but
anyhow, rmt in lenny had better work at all.
Cheers,
--
/Awesome Walrus wal...@amur.ru
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
