#2285 Issue closed: Show disklayout.conf and diskrestore.sh content in "rear -D recover" log¶
Labels: enhancement, discuss / RFC, no-issue-activity
jsmeix opened issue at 2019-11-25 13:08:¶
Basically always when there is a user report where "rear recover"
failed
I would like to see the user's disklayout.conf and diskrestore.sh
to have it easier to imagine what goes on on the user's system.
Therefore I would like to print the disklayout.conf and diskrestore.sh
content
into the "rear -D recover" log (i.e. only in case of debugscript mode).
What I worry about is that disklayout.conf and diskrestore.sh
can contain secrets, e.g. "Disk layout file syntax" in
https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc
reads (excerpt)
LUKS Devices
crypt ... [cipher=<cipher>] ... [password=<password>]
...
TCG Opal 2-compliant Self-Encrypting Disks
opaldisk ... [password=<password>]
which means the "rear -D recover" log can contain secrets, cf.
https://github.com/rear/rear/pull/2156
On the other hand I assume that currently the "rear -D recover" log
may already contain the cipher and password values for LUKS
and/or TCG Opal 2-compliant Self-Encrypting Disks
via the normal set -x output.
jsmeix commented at 2019-11-25 13:10:¶
@OliverO2
FYI see this issue
https://github.com/rear/rear/issues/2285
because it is also about that ReaR's debugscript log may contain
the password value for TCG Opal 2-compliant Self-Encrypting Disks
via the set -x output, cf.
https://github.com/rear/rear/pull/2156
OliverO2 commented at 2019-11-25 17:31:¶
@jsmeix
I just had a short look, but to me it seems like the password is
protected from appearing in the log:
https://github.com/rear/rear/blob/307f1f3ed20449f893e2d92aa2ba37621a75f1ba/usr/share/rear/layout/prepare/GNU/Linux/180_include_opaldisk_code.sh#L55
jsmeix commented at 2019-11-26 09:21:¶
@OliverO2
from plain looking at the code of the create_opaldisk function
I think it only switches off set -x inside diskrestore.sh
while the confidential commands are running
but I think it does not redirect stderr to /dev/null
while the create_opaldisk function is running.
So I think set -x output may appear in the log
while create_opaldisk is running.
On the other hand it seems $OPAL_DISK_PASSWORD
is nowhere evaluated while the create_opaldisk function is running
because it is always used as \$OPAL_DISK_PASSWORD so that
$OPAL_DISK_PASSWORD is only evaluated while diskrestore.sh
is running and there set -x is switched off.
But I found unescaped $OPAL_DISK_PASSWORD
several times in various functions in
usr/share/rear/lib/opaladmin-workflow.sh
On first glance I cannot see whether or not set -x could be set
while those functions are running.
OliverO2 commented at 2019-11-26 13:11:¶
Yes, the opaladmin workflow contains no special debugscripts
protection. But this is an isolated workflow which does not interfere
with the rest of ReaR.
If a need should arise to debug this workflow with -x and send out the
log, the user should use demo passwords only or scrutinize the log for
any production password used.
github-actions commented at 2020-06-29 01:37:¶
Stale issue message
[Export of Github issue for rear/rear.]