Description of problem: Restore can not restore compressed dumps located on remote systems, moreover it crashes after receiving a fatal signal. Version-Release number of selected component (if applicable): dump-0.4b41-2.fc6 How reproducible: Always. Steps to Reproduce: Create a compressed dump file. Uncompressed one won't do. # mkdir somedir # dump zf somedir.dump somedir DUMP: Date of this level dump: Wed Mar 21 17:20:59 2007 ... DUMP: DUMP IS DONE # Attempt to access it locally succeeds... $ RSH=ssh restore if somedir.dump Dump tape is compressed. restore > what Dump date: Wed Mar 21 17:21:49 2007 Dumped from: the epoch Level 0 dump of / (dir home/lkundrak/somedir) on pluto:/dev/mapper/vg00-root Label: none restore > ...whereas remote restore via SSH fails: $ RSH=ssh restore if localhost:somedir.dump Connection to localhost established. Dump tape is compressed. short compressed block: 32772 expected: 135005703 decompression error, block 33: length mismatch Segmentation fault (core dumped) $ Additional info: I haven't looked at this at all, so just in case I set this to private for now and open just for security sensitive group, as there might be a memory corruption. It also might be that the Priority I set is too high.
$ gdb restore restore-13333.core ... Core was generated by `restore if localhost:somedir.dump'. Program terminated with signal 11, Segmentation fault. #0 0x000000000046f0d3 in _wordcopy_fwd_dest_aligned () (gdb) bt #0 0x000000000046f0d3 in _wordcopy_fwd_dest_aligned () #1 0x000000000046ebdf in memmove () #2 0x000000000040da53 in readtape_comprtape (buf=0x7fff8fef0c80 "") at tape.c:2151 #3 0x000000000040d11e in readtape (buf=0x7fff8fef0c80 "") at tape.c:1890 #4 0x000000000040bf7f in getfile (fill=0x40c3ba <xtrmap>, skip=0x40c3f6 <xtrmapskip>) at tape.c:1311 #5 0x000000000040a807 in setup () at tape.c:417 #6 0x00000000004057c0 in main (argc=1, argv=0x768650) at main.c:488 #7 0x000000000044b470 in __libc_start_main () #8 0x00000000004001b9 in _start () (gdb)
Is not SSH specific. $ RSH=rsh restore if localhost:somedir.dump Connection to localhost established. connect to address 127.0.0.1 port 544: Connection refused Trying krb4 rsh... connect to address 127.0.0.1 port 544: Connection refused trying normal rsh (/usr/bin/rsh) Dump tape is compressed. short compressed block: 32772 expected: 135005703 decompression error, block 33: length mismatch Segmentation fault (core dumped) $
Seems just like an out-of-bound read, with no possible security implications. Making public. #2 0x000000000040da53 in readtape_comprtape (buf=0x7fffd959ef00 "") at tape.c:2151 2151 memmove(buf, &tbufptr[(blkcnt++ * TP_BSIZE)], TP_BSIZE); (gdb) print &tbufptr[(blkcnt++ * TP_BSIZE)] Cannot access memory at address 0x75baa0 (gdb) print TP_BSIZE $5 = 1024 (gdb) print blkcnt $6 = 126 (gdb)
Not a bug, see the restore man page: " -l When doing remote restores, assume the remote file is a regular file (instead of a tape device). If you’re restoring a remote compressed file, you will need to specify this option or restore will fail to access it correctly. " With the -l, restore does perform correctly.
(In reply to comment #4) Thanks much for your very fast feedback. But I think that segfault is bad end (even thought this due user mistake). I think restore could write something like "could not access device" or "you must specify -l option when doing remote restore", not segfault. I could write proposed patch but are you going to accept that patch or no patch is needed for issues like this. Regards, -A-
adding upstream to CC, please see comment #5
Of course it would be better to handle the error gracefully, but unfortunately this is hard if possible at all. The main problem is that compression on tape and compression on file are two different beasts (mainly because of the blocking factor of the tape drive), and need two different algorithms to decompress. In order to use the right algorithm, restore needs to know if the media is a tape or a file. For a local tape/file it's quite simple (restore issues a MTIOCGET ioctl and if this fails then it assumes the media is a file). Things are more difficult when the media is accessed remotely. rmt(1) protocol is quite limited, and has real compatability problems when used in mixed environments (Linux dump, other OS tape server). A while ago, dump/restore tried to autodetect the remote media type. However, this caused problems, and this is why dump-0.4b25, in november 2001, added the -l option. From the CHANGES file: Add the -l option to restore to specify if, when doing a remote restore, the file used to access the backup is a regular file (the defaults being a tape drive). Restore needs to know this information when reading a remote compressed dump. Previously, this information was autodetected, but the autodetection code fails (with ioctl: Inappropriate ioctl for device) when using a non Linux remote box. Thanks to many users and especially to Eros Albertazzi <eros.cnr.it> for reporting this. This is quite old, and I don't remember exactly what the problems were. But on the other side, this is the first time someone complains about this since 2001, so I would simply consider this bug to be a feature and close it with a WONTFIX :-)
(In reply to comment #7) Don't waste time with this, closing