ca-certificates directory to ReaR recovery system for Arch Linux¶

Labels: enhancement, fixed / solved / done

gozora opened issue at 2018-11-19 17:37:¶

Pull Request Details:¶

Type: Enhancement
Impact: Low
Reference to related issue (URL): N/A
How was this pull request tested?
By running rear mkrescue on Arch Linux.
Brief description of the changes in this pull request:

On current Arch (rolling release), SSL certificates are symlinked from /etc/ssl/certs to /etc/ca-certificates/extracted/cadir.
This is causing ReaR to complaint about broken symlinks when running rear mkrescue/mkbackup:

Broken symlink './etc/ssl/certs/QuoVadis_Root_CA_1_G3.pem' in recovery system because 'readlink' cannot determine its link target
Broken symlink './etc/ssl/certs/1e09d511.0' in recovery system because 'readlink' cannot determine its link target
Broken symlink './etc/ssl/certs/Staat_der_Nederlanden_Root_CA_-_G2.pem' in recovery system because 'readlink' cannot determine its link target
...

jsmeix commented at 2018-11-20 12:03:¶

Could SSL certificates be in any way private data (i.e. secrets)?

By default the ReaR recovery system must not contain any
private data or secrets from the original system.

If something in the /etc/ca-certificates/ directory could be
private data or secrets, an unconditioned

COPY_AS_IS=( "${COPY_AS_IS[@]}" '/etc/ca-certificates/*' )

is not possible, cf.
https://github.com/rear/rear/pull/1402#issuecomment-312809863

schlomo commented at 2018-11-20 12:10:¶

By design, CA certificates should go there which are public in nature.

gozora commented at 2018-11-22 09:44:¶

If there are not further objections, I'll merge this PR later today.

@schlomo, @jsmeix thanks for your enlighting on nullglob topic!

V.

jsmeix commented at 2018-11-26 10:59:¶

I think since this was merged I get (excerpts):

# usr/sbin/rear -D mkrescue
...
Testing that the recovery system in /tmp/rear.9hOdTOx8wpnxtEb/rootfs contains a usable system
Failed to copy symlink target '/var/lib/ca-certificates/pem'
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression

investigating...

jsmeix commented at 2018-11-26 11:34:¶

The above Failed to copy symlink target happens in
build/default/985_fix_broken_links.sh

At least the ordering of the scripts at this area is wrong:

# usr/sbin/rear -s mkrescue
...
Source build/default/970_add_rear_release.sh
Source build/default/980_verify_rootfs.sh
Source build/default/985_fix_broken_links.sh
Source build/default/990_update_os_conf.sh
Source build/default/995_md5sums_rootfs.sh

It should be (do the verification at the end):

usr/share/rear/build/default/970_add_rear_release.sh
usr/share/rear/build/default/975_update_os_conf.sh
usr/share/rear/build/default/985_fix_broken_links.sh
usr/share/rear/build/default/990_verify_rootfs.sh
usr/share/rear/build/default/995_md5sums_rootfs.sh

jsmeix commented at 2018-11-26 12:09:¶

Since the change of this pull request /etc/ssl/certs
has become a broken symlink in the recovery system

# chroot /tmp/rear.eQshuna9VErWIid/rootfs find . -xdev -path ./proc -prune -o -path ./sys -prune -o -path ./dev -prune -o -xtype l -print
./etc/localtime
./etc/ssl/certs
./etc/mtab
./etc/termcap

# file /tmp/rear.eQshuna9VErWIid/rootfs/etc/ssl/certs
/tmp/rear.eQshuna9VErWIid/rootfs/etc/ssl/certs: symbolic link to /var/lib/ca-certificates/pem

# ls /tmp/rear.eQshuna9VErWIid/rootfs/var/lib/ca-certificates/pem
ls: cannot access '/tmp/rear.eQshuna9VErWIid/rootfs/var/lib/ca-certificates/pem': No such file or directory

When I revert the change of this pull request etc/ssl/certs
is not reported as broken symlink in the recovery system:

# chroot /tmp/rear.9w3htbY8andZlEO/rootfs find . -xdev -path ./proc -prune -o -path ./sys -prune -o -path ./dev -prune -o -xtype l -print
./etc/localtime
./etc/mtab
./etc/termcap

# file /tmp/rear.9w3htbY8andZlEO/rootfs/etc/ssl/certs
/tmp/rear.9w3htbY8andZlEO/rootfs/etc/ssl/certs: directory

where that /tmp/rear.9w3htbY8andZlEO/rootfs/etc/ssl/certs directory
contains all the files from /var/lib/ca-certificates/pem on the original system.

Accordingly since this was merged there is the regression
that the recovery system does no longer contain the files
from /var/lib/ca-certificates/pem on the original system.

jsmeix commented at 2018-11-26 12:21:¶

With

COPY_AS_IS=( "${COPY_AS_IS[@]}" '/etc/ssl/certs/*' '/etc/pki/*' '/usr/lib/ssl/*' '/usr/share/ca-certificates/*' '/etc/ca-certificates/*' )

it works for me again.

I will now just blindly hack that into usr/share/rear/conf/GNU/Linux.conf
to get this regression out of sight for now...

I leave it to others who (hopefully) better than I understand the subtle
differences to explain the reason behind that regression and could
perhaps even provide a proper fix later...

There are too many things in ReaR that work in too subtle ways...

jsmeix commented at 2018-11-26 12:29:¶

Hopefully now fixed via
https://github.com/rear/rear/commit/19bef9d45756ba8798c6c8e5e7bf3b66eb746479
(and https://github.com/rear/rear/commit/e2ee649b13dd06b3e10b215cfc61a3f4b1bb685d)

jsmeix commented at 2020-05-25 13:40:¶

The reason why /etc/ssl/certs/* works
but /etc/ssl/certs fails is described in
https://github.com/rear/rear/pull/2405#issuecomment-633573036

Our ugly code places re-appear again and again until someone
hopefully may finally get sufficiently angry to actually fix them ;-)

[Export of Github issue for rear/rear.]

#1971 PR merged: Add /etc/ca-certificates directory to ReaR recovery system for Arch Linux¶