#679 Issue closed: cryptsetup pw dict files missing

Labels: bug, fixed / solved / done

thepulze opened issue at 2015-10-29 20:25:

Using Relax-and-Recover 1.17.2, restore of a CentOS 7.1.1503 system with crypto sw raid partition.

Restore process crashed because of missing pw dictionary files, used for pw quality check. Manually copying pw files to /usr/share/cracklib fixes the problem - resuming script execution worked afterwards.

Log:

+++ echo -e 'Please enter the password for vm-01(/dev/mapper/vg0-vm):'
+++ cryptsetup luksFormat -q --cipher aes-xts-plain64 --hash sha1 --uuid 9177bf34-a4b6-445c-8d02-ab39a06f4637 /dev/mapper/vg0-vm
/usr/share/cracklib/pw_dict.pwd.gz: No such file or directory
Password quality check failed:
The password fails the dictionary check - error loading dictionary
2015-10-29 19:10:21 An error occurred during layout recreation.

gdha commented at 2015-11-02 08:10:

@thepulze I am trying to understand what the easiest way is to identify if crypted devices are in use:

  1. presence of /etc/crypttab file ?
  2. non-empty output of sudo dmsetup ls --target crypt ?
  3. the presence of lsmod | grep dm-crypt ?
  4. use cryptsetup -v isLuks <device> exit code ?
  5. output of blkid -p <device> ?

We are thinking of making some kind of prep phase script which could be used to identify, and make sure that are desired executables, libraries and configuration files are copied to the rescue image.

gdha commented at 2016-02-22 15:45:

Due to no fb close this issue

tastle73 commented at 2016-02-22 21:14:

@gdha We have run into this same problem. I am happy to be a tester.

ReaR seems to be detecting that a luks volume is there just fine on its own and it would rebuild the luks partitions at rescue if not for the dictionary error. In fact, if you just add --force-password to the cryptsetup command in the rebuild script it will.

However, it is not pulling all the password quality dictionaries needed for cryptsetup to run. I tried adding different libraries to the default conf file LIBS section but couldn't get it to work.

gdha commented at 2016-02-23 16:21:

@tastle73 perhaps with the help of strace you could try to find out what it really wants.

tastle73 commented at 2016-02-23 16:22:

I'm all ears. How could I do this?

gdha commented at 2016-02-23 16:43:

Edit in script diskrestore.sh that is created during the recover phase and add the strace before the cryptsetup command (use the menu to edit the diskrestore.sh script), e.g.

$ strace cryptsetup 
execve("/usr/sbin/cryptsetup", ["cryptsetup"], [/* 52 vars */]) = 0
brk(0)                                  = 0x1f2e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fca4643a000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=89701, ...}) = 0
mmap(NULL, 89701, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fca46424000
close(3)                                = 0
and so on...

tastle73 commented at 2016-02-23 17:02:

Just so you're aware, I ran ldd against cryptsetup while trying to fix it and found that it needed libpwquality.so.1 So I added that

[root@rj ~]# ldd which cryptsetup
linux-vdso.so.1 => (0x00007ffca6d06000)
libcryptsetup.so.4 => /lib64/libcryptsetup.so.4 (0x00007f55ee327000)
libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f55ee11d000)
libpwquality.so.1 => /lib64/libpwquality.so.1 (0x00007f55edf16000)
libc.so.6 => /lib64/libc.so.6 (0x00007f55edb55000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f55ed950000)
libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007f55ed6f5000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f55ed474000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f55ed270000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f55ed06a000)
libcrack.so.2 => /lib64/libcrack.so.2 (0x00007f55ece5f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f55ee560000)
librt.so.1 => /lib64/librt.so.1 (0x00007f55ecc57000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f55eca31000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x00007f55ec7ec000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f55ec7d7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f55ec5ba000)
libm.so.6 => /lib64/libm.so.6 (0x00007f55ec2b8000)
libz.so.1 => /lib64/libz.so.1 (0x00007f55ec0a2000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f55ebe40000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f55ebc1b000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f55eba16000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f55eb7ce000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f55eb5b8000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f55eb3b3000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f55eb19c000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f55eaf8c000)

tastle73 commented at 2016-02-29 19:14:

I ran strace as instructed and was able to determine what the dependancies are. I added them to default.conf in the COPY_AS_IS variable:

COPY_AS_IS=( /usr/share/cracklib/* /etc/security/pwquality.conf $SHARE_DIR $VAR_DIR )

With this added, LUKS volumes are recreated as expected.

Would you be able to have rear copy these in when LUKS is encountered?

On Feb 23, 2016, at 11:43 AM, gdha notifications@github.com wrote:

Edit in script diskrestore.sh that is created during the recover phase and add the strace before the cryptsetup command (use the menu to edit the diskrestore.sh script), e.g.

$ strace cryptsetup
execve("/usr/sbin/cryptsetup", ["cryptsetup"], [/* 52 vars */]) = 0
brk(0) = 0x1f2e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fca4643a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=89701, ...}) = 0
mmap(NULL, 89701, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fca46424000
close(3) = 0
and so on...
—
Reply to this email directly or view it on GitHub https://github.com/rear/rear/issues/679#issuecomment-187783357.

Thomas Astle
System Administrator

Physician's Computer Company
20 Winooski Falls Way, Suite 7
Winooski, VT 05404
+1 800.722.7708
tom@pcc.com

gdha commented at 2016-03-04 13:16:

@tastle73 thank you - your advise was useful. Committed it for 1.18.

tastle73 commented at 2016-03-04 17:53:

As a test I did a git pull today and ran make rpm. For some reason mdadm was missing at restore time. Copying it in from another system worked.

[Export of Github issue for rear/rear.]