dump bundles minilzo, which is affected by the CVE-2014-4607 issue from the LZO library. Patched packages uploaded for Mageia 3, Mageia 4, and Cauldron by Oden. Oden has asked us to test this one more extensively, i.e. to actually test its use of lzo (because the patch was more involved in this case). You can use the dump command with the -y option to make a compressed backup to a file, and then use the restore command to extract it. It would look something like this: dump -y -f backup.dump files-and-dirs-to-backup restore -C -f backup.dump That restore command won't actually extract, it'll just compare the backed up files to the ones on disk and tell you if any don't match (if I understand the man pages correctly). Advisory: ======================== Updated dump packages fix security vulnerability: An integer overflow in liblzo before 2.07 allows attackers to cause a denial of service or possibly code execution in applications using performing LZO decompression on a compressed payload from the attacker (CVE-2014-4607). The dump package is built with a bundled copy of minilzo, which is a part of liblzo containing the vulnerable code. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4607 http://advisories.mageia.org/MGASA-2014-0290.html ======================== Updated packages in core/updates_testing: ======================== dump-0.4b44-2.1.mga3 rmt-0.4b44-2.1.mga3 dump-0.4b44-3.1.mga4 rmt-0.4b44-3.1.mga4 from SRPMS: dump-0.4b44-2.1.mga3.src.rpm dump-0.4b44-3.1.mga4.src.rpm Reproducible: Steps to Reproduce:
Blocks: (none) => 13943Whiteboard: (none) => MGA3TOO
Whiteboard: MGA3TOO => MGA3TOO has_procedure
In VirtualBox, M3, KDE, 32-bit Package(s) under test: dump rmt default install of dump & rmt [root@localhost wilcal]# urpmi dump Package dump-0.4b44-2.mga3.i586 is already installed [root@localhost wilcal]# urpmi rmt Package rmt-0.4b44-2.mga3.i586 is already installed (In reply to David Walser from comment #0) > Oden has asked us to test this one more extensively, i.e. to actually test > its use of lzo (because the patch was more involved in this case). You can > use the dump command with the -y option to make a compressed backup to a > file, and then use the restore command to extract it. It would look > something like this: > > dump -y -f backup.dump files-and-dirs-to-backup > restore -C -f backup.dump "It would look something like this:" ??? I have a directory: /home/wilcal/mageia_3_install in which there are 27 files I have created /home/wilcal/dump Please have Oden share with us the exact dump command he wants using this directory as a source. I've tried a number of dump commands that don't work. I'm not familiar with dump. Lets also get a "restore" command that takes the dump file contained in /home/wilcal/dump and restore that to /home/wilcal/dump_restore dump -y -f /home/wilcal/dump backup.dump /home/wilcal/mageia_3_install results in: [root@localhost wilcal]# dump -y -f /home/wilcal/dump backup.dump /home/wilcal/mageia_3_install DUMP: Date of this level 0 dump: Wed Sep 3 09:51:06 2014 DUMP: Dumping backup.dump (an unlisted file system) to /home/wilcal/dump DUMP: Cannot open backup.dump DUMP: The ENTIRE dump is aborted. [root@localhost wilcal]# dump -y /home/wilcal/dump backup.dump -f /home/wilcal/mageia_3_install DUMP: Date of this level 0 dump: Wed Sep 3 09:53:50 2014 DUMP: Dumping /dev/sda6 (/home (dir /wilcal/dump)) to /home/wilcal/mageia_3_install DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: Compressing output (lzo) DUMP: mapping (Pass I) [regular files] DUMP: File cannot be accessed (backup.dump). DUMP: The ENTIRE dump is aborted. I'm sure I've got something wrong in the syntax somewhere. Thanks Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver virtualbox-4.3.10-1.1.mga4.x86_64 virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64
CC: (none) => wilcal.int
Yes you messed up the command. Should be: dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install Doing a restore to extract is not necessary, a Compare is fine: restore -C -f /home/wilcal/dump/backup.dump
In VirtualBox, M3, KDE, 32-bit Package(s) under test: dump rmt default install of dump & rmt [root@localhost wilcal]# urpmi dump Package dump-0.4b44-2.mga3.i586 is already installed [root@localhost wilcal]# urpmi rmt Package rmt-0.4b44-2.mga3.i586 is already installed dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install backup a local directory to file backup.dump restore -r -f backup.dump restores files in backup.dump into /home/wilcal/dump install dump & rmt from updates_testing [root@localhost wilcal]# urpmi dump Package dump-0.4b44-2.1.mga3.i586 is already installed [root@localhost wilcal]# urpmi rmt Package rmt-0.4b44-2.1.mga3.i586 is already installed dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install backup a local directory to file backup.dump restore -r -f backup.dump restores files in backup.dump into /home/wilcal/dump_14047 Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 4 64-bit, Nvidia driver virtualbox-4.3.10-1.1.mga4.x86_64 virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64
Have you run a Compare (the -C option I said earlier) to ensure that the uncompressed data is the same as the original data?
(In reply to David Walser from comment #4) > Have you run a Compare (the -C option I said earlier) to ensure that the > uncompressed data is the same as the original data? restore -C -f backup.dump Showing 58 compare errors and a bunch of ./wilcal/.mozilla: (inode 130310) not found on tape errors. And nothing gets restored.
(In reply to William Kenney from comment #5) > (In reply to David Walser from comment #4) > > > Have you run a Compare (the -C option I said earlier) to ensure that the > > uncompressed data is the same as the original data? > > restore -C -f backup.dump > > Showing 58 compare errors and a bunch of that's not good > ./wilcal/.mozilla: (inode 130310) not found on tape Why is it looking for that? I thought you created the dump file by backing up /home/wilcal/mageia_3_install > errors. And nothing gets restored. It's not supposed to restore anything.
(In reply to David Walser from comment #6) > > Showing 58 compare errors and a bunch of > > that's not good...... I'm pretty confident that the dump & restore commands, even through executed as sysadmin, arn't gonna screw up my production M4 i586 system so I'll tinker with them here. And it's on real hardware. I think we should be able to get this thing down to two simple command lines. I think the first one works fine and that's: dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_4_install First I create /home/wilcal/dump Then: [root@shermanm4 wilcal]# dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_4_install DUMP: Date of this level 0 dump: Wed Sep 3 15:40:59 2014 DUMP: Dumping /dev/sda6 (/home (dir /wilcal/mageia_4_install)) to /home/wilcal/dump/backup.dump DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: Compressing output (lzo) DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 52204 blocks. DUMP: Volume 1 started with block 1 at: Wed Sep 3 15:40:59 2014 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /home/wilcal/dump/backup.dump DUMP: Volume 1 completed at: Wed Sep 3 15:41:01 2014 DUMP: Volume 1 took 0:00:02 DUMP: Volume 1 transfer rate: 18477 kB/s DUMP: Volume 1 52190kB uncompressed, 36955kB compressed, 1.413:1 DUMP: 52190 blocks (50.97MB) on 1 volume(s) DUMP: finished in 2 seconds, throughput 26095 kBytes/sec DUMP: Date of this level 0 dump: Wed Sep 3 15:40:59 2014 DUMP: Date this dump completed: Wed Sep 3 15:41:01 2014 DUMP: Average transfer rate: 18477 kB/s DUMP: Wrote 52190kB uncompressed, 36955kB compressed, 1.413:1 DUMP: DUMP IS DONE That creates /home/wilcal/dump/backup.dump No errors are reported so I assume everything went just fine. I don't have to be in /home/wilcal/dump to make it happen. So I think we can agree that this is a success. Now we should be able to extract the archived files into the same directory using restore. In /home/wilcal/dump I do this: [root@shermanm4 dump]# restore -r -f backup.dump Dump tape is compressed. ./lost+found: (inode 11) not found on tape ./live: (inode 12) not found on tape ./wilcal/.MgaOnline: (inode 49020930) not found on tape ./wilcal/.bash_completion: (inode 49020932) not found on tape ./wilcal/.bash_logout: (inode 49020933) not found on tape ./wilcal/.bash_profile: (inode 49020934) not found on tape ./wilcal/.bashrc: (inode 49020935) not found on tape ./wilcal/.desktop: (inode 49020931) not found on tape ....... ....... ....... ./wilcal/advisories: (inode 49021151) not found on tape ./wilcal/.Skype: (inode 49021120) not found on tape ./wilcal/.cddb: (inode 49152696) not found on tape ./wilcal/dump: (inode 49022487) not found on tape Not quite sure what all that is about but indeed the backed up directory was restored as: /home/wilcal/dump/wilcal/mageia_4_install So now I have the original directory and the restored directory. Lets see if the restore -C works one against the other. restore -C -f /home/wilcal/dump/backup.dump /home/wilcal/dump/wilcal/mageia_4_install just gets me lots of the same thing as in "not found on tape" above. Tomorrow more tinkering.
Testing complete mga4 64 Testing this slightly differently. From the man page and some googling: restore -C, which is to check/compare the dump file with the filesystem, first cd's to the filesystem root. That is normally going to be /home. It then shows 'not found on tape' errors for each file in /home which is not on the tape, or dump file in this case. Running it interactively instead, as if to perform the restore, it is possible to change directory, add the dumped directory to be restored and list it's contents. Restore actually states that the dump file is compressed, so it is then able to read the compression, which is the crux of this update. I didn't extract the files as it's a potentially hazardous process. Started in directory 'test' I made directory 'stuff' and copied some random test files into it. $ cd test $ ls stuff/ $ ls stuff/ test2.apc test.dxf~ testing testphp-memcache1.php testphp-pear.php test.sh~* testxml.py testdata.xml test.fig testoutput.prn testphp-memcache2.php test.py test.tar testxsel.sh test.dxf test.gif testphp-mbstring.php testphp-memcache.php test.sh testtest.iso I used sudo but you could 'su' (without the -) if you prefer. $ sudo dump -y -f stuff.dump stuff DUMP: Date of this level 0 dump: Mon Sep 8 14:37:13 2014 DUMP: Dumping /dev/mapper/vg--mga-home (/home (dir /claire/test/stuff)) to stuff.dump DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: Compressing output (lzo) DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 7170 blocks. DUMP: Volume 1 started with block 1 at: Mon Sep 8 14:37:13 2014 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing stuff.dump DUMP: Volume 1 completed at: Mon Sep 8 14:37:13 2014 DUMP: 7170 blocks (7.00MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Mon Sep 8 14:37:13 2014 DUMP: Date this dump completed: Mon Sep 8 14:37:13 2014 DUMP: Average transfer rate: 0 kB/s DUMP: Wrote 7170kB uncompressed, 2598kB compressed, 2.760:1 DUMP: DUMP IS DONE $ ll total 2604 drwxr-xr-x 2 claire claire 4096 Sep 8 13:52 stuff/ -rw-r--r-- 1 root root 2660771 Sep 8 14:37 stuff.dump $ sudo restore -i -f stuff.dump Dump tape is compressed. restore > cd claire/test restore > ls ./claire/test: stuff/ restore > add stuff restore > ls ./claire/test: *stuff/ restore > ls stuff ./claire/test/stuff: *test.dxf *test.tar *testphp-memcache1.php *test.dxf~ *test2.apc *testphp-memcache2.php *test.fig *testdata.xml *testphp-pear.php *test.gif *testing *testtest.iso *test.py *testoutput.prn *testxml.py *test.sh *testphp-mbstring.php *testxsel.sh *test.sh~ *testphp-memcache.php restore > quit This doesn't actually extract anything but does create a directory structure (claire/test/stuff) in the test directory, owned by root. Be careful when deleting it.. $ ll total 2608 drwx------ 3 root root 4096 Sep 8 14:43 claire/ drwxr-xr-x 2 claire claire 4096 Sep 8 13:52 stuff/ -rw-r--r-- 1 root root 2660771 Sep 8 14:37 stuff.dump $ sudo rm -rf claire $ sudo rm stuff.dump
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga4-64-ok
Still, does that confirm that it can produce uncompressed data that matches the original data?
It shows it can read the lzo compressed dump file AFAICT. I haven't found a way to use -C and restrict it to the dumped directory. It's not really a tar kind of tool, it's more aimed at backing up block devices. The errors shown in restore -C -f stuff.dump are all 'not found on tape' and relate to the files/directories in /home (on my system where /home is a partition) not having been included in the dump. Crucially though it doesn't complain that it is unable to read the lzo compressed dump. I'm not prepared to extract the files to test beyond this due to the block nature and possible root owned filesystem it may leave in it's wake.
(In reply to David Walser from comment #9) > Still, does that confirm that it can produce uncompressed data that matches > the original data? After spending too many decades in the backup/restore industry. Best way to test a backup system is to execute the backup to some media, whatever that is. Restore it to something else, whatever that is. Then compare the original media that was backed up to what was restored. You then count the errors. 1 error in 10-13th was common for tape. At the level we should be testing dump/restore we should see any errors.
(In reply to William Kenney from comment #11) > for tape. At the level we should be testing dump/restore > we should see any errors. s/b > for tape. At the level we should be testing dump/restore > we should not see any errors.
With -v for verbose.. $ sudo restore -C -v -f stuff.dump <.. snip lots of 'not found on tape' errors..> Begin compare restore Verify tape and initialize maps Input is from a local file/pipe Input block size is 10 Dump date: Mon Sep 8 15:45:33 2014 Dumped from: the epoch Level 0 dump of /home (dir /claire/test/stuff) on localhost:/dev/mapper/vg--mga-home Label: none filesys = /home Initialize symbol table. Extract directories from tape comparing ./claire/test/stuff/test2.apc (size: 9189, mode: 0100644) comparing ./claire/test/stuff/testdata.xml (size: 694, mode: 0100644) comparing ./claire/test/stuff/test.dxf (size: 12306, mode: 0100644) comparing ./claire/test/stuff/test.dxf~ (size: 12066, mode: 0100644) comparing ./claire/test/stuff/test.fig (size: 327, mode: 0100644) comparing ./claire/test/stuff/test.gif (size: 2831, mode: 0100644) comparing ./claire/test/stuff/testing (size: 0, mode: 0100644) comparing ./claire/test/stuff/testoutput.prn (size: 260971, mode: 0100644) comparing ./claire/test/stuff/testphp-mbstring.php (size: 556, mode: 0100644) comparing ./claire/test/stuff/testphp-memcache1.php (size: 841, mode: 0100644) comparing ./claire/test/stuff/testphp-memcache2.php (size: 267, mode: 0100644) comparing ./claire/test/stuff/testphp-memcache.php (size: 1015, mode: 0100644) comparing ./claire/test/stuff/testphp-pear.php (size: 321, mode: 0100644) comparing ./claire/test/stuff/test.py (size: 106, mode: 0100644) comparing ./claire/test/stuff/test.sh (size: 307, mode: 0100644) comparing ./claire/test/stuff/test.sh~ (size: 308, mode: 0100744) comparing ./claire/test/stuff/test.tar (size: 0, mode: 0100644) comparing ./claire/test/stuff/testtest.iso (size: 3819520, mode: 0100600) comparing ./claire/test/stuff/testxml.py (size: 267, mode: 0100644) comparing ./claire/test/stuff/testxsel.sh (size: 107, mode: 0100644) Compare directories modes, owner, attributes. comparing directory . comparing directory ./claire comparing directory ./claire/test comparing directory ./claire/test/stuff Check the symbol table. Some files were modified! 342 compare errors
Testing complete mga3 32 As before.. $ sudo dump -y -v -f stuff.dump stuff The -v here doesn't really add anything. It already shows it compresses the data. $ sudo restore -C -v -f stuff.dump Adding the -v for verbose shows the compares at the end of the 'not found on tape' errors.
Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-64-ok
Testing complete mga4 32 As comment 14
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok
In VirtualBox, M3, KDE, 64-bit Package(s) under test: dump default install of dump [root@localhost dump]# urpmi dump Package dump-0.4b44-2.mga3.x86_64 is already installed dump -y -v -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install creates the backup.dump file restore -r -f backup.dump restores backup.dump to /home/wilcal/dump/ restore -C -v -f backup.dump compares backup.dump to /home/wilcal/mageia_3_install install dump rmt from updates_testing [root@localhost dump]# urpmi dump Package dump-0.4b44-2.1.mga3.x86_64 is already installed dump -y -v -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install creates the backup.dump file restore -r -f backup.dump restores backup.dump to /home/wilcal/dump/ restore -C -v -f backup.dump compares backup.dump to /home/wilcal/mageia_3_install
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
For me this update works fine. Testing complete for mga3 32-bit & 64-bit Testing complete for mga4 32-bit & 64-bit I'm not entirely happy with the way we are testing this but from what I can see the update is successful. If I don't hear from anyone else in 24-hours I'll validate it.
Advisory uploaded.
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
Validating the update. Could someone from the sysadmin team push this to updates. Thanks
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0378.html
Status: NEW => RESOLVEDResolution: (none) => FIXED