RFC: Investigate read-only mounting during "rear recover"

[jsmeix]

This issue is triggered by
#2886
therein in particular my comments (excerpts):

the USB disk content has to be sacrosanct during "rear recover"
...
during "rear recover" nothing of what there is
on the USB disk should ever be changed by ReaR.

cf. #1271

During "rear recover" all what matches ReaR sources
like /dev/disk/by-label/REAR-000 or BACKUP_URL=usb://...
must be sacrosanct

So I would like to investigate if it is feasible
and possible to implement with reasonable effort
to mount things read-only during "rear recover"
when things are only needed to be read
e.g. to restore a backup.tar.gz.

I think during "rear recover" some things may need to be
written (e.g. a some log file or something like that)
which could make it rather complicated to mount things
read-only.

See also
WRITE_PROTECTED_IDS and WRITE_PROTECTED_FS_LABEL_PATTERNS
and the related issue
#1271
with its pull requests
#2626
and
#2703

[pcahyna]

The log gets written into the recovered system, not on the medium, AFAIK. (Writing to the medium would be USB-specific.)

[pcahyna]

Also, one may even improve this by setting the device read-only at the block device level, i.e. by blockdev --setro. This should prevent the layout code from accidentally reformatting it.

[jsmeix]

I think some log might be written to a mounted NFS share
(this issue is not only about USB but meant in general)
but that is a totally offhanded (untested) guess.

[github-actions]

Stale issue message

[schlomo]

I'm also in favour of mounting all external media/file shares read-only. That is a good example for defensive programming and it can save some users from accidentially erasing their backups

[DEvil0000]

not sure if all backup tools would be happy with a ro filesystem. The for the system partition/image ro may make sense but for data/backup partition/files this hardly depends on the mechanism/tooling used. Also I would personally like to have a log file on the recovery media as well. Sometimes it is a good thing being able to install packages on a recovery system later - for example because the HW like RAID controller or network card changed.
If it would be a ro filesystem we may want some kind of persisted or temporary overlay rw partition as well.

I do not see a big plus in a ro recovery filesystem and you can get this already by kernel parameters or fstab entries without the need to change any line in rear, just config.

Note: I hate being the conservative voice -.-

[schlomo]

@DEvil0000 I think the question was not about the rootfs of the rescue system (which is in-memory in any case and ephemeral) but about external media, e.g. NFS shares or USB drives, that contain backup data and that we currently mount read-write even though we only need to read from them.

"sacrosanct" meaning that we should mount those read-only to prevent potential coding or configuration errors from accidentally erasing the backups.

[DEvil0000]

"sacrosanct" meaning that we should mount those read-only to prevent potential coding or configuration errors from accidentally erasing the backups.

I know that this is your reasoning - which is very valid. I however do not know all the backup backends possible with rear but I can think of one organizing the data in some kind of database and needing some sort of rw for example to mark which files got restored and when.
This may be a hypothetical and not so much a real case but we should at least check for all backends if they are fine with ro.
Also as said one can configure rear to mount things ro even with the current version so is there a real need for such a change?

[github-actions]

Stale issue message