Package: os-prober Severity: critical Justification: causes serious data loss
Hey. AFAIU, os-prober still falls back to using the non grub-mount based probing, when the later isn't available. Also os-prober doesn't in anyway depend on grub, so there is absolutely no guarantee it would be available. Now looking at the non-based probing and it's issues: 1) As already reported in several other open bugs, it may cause data corruptions, as mount -r doesn't mean that nothing on disk may be change. Typical example is replaying the log of journalled filesystems but als non journaled filesystems have a log (e.g. btrfs, though it's not used there for journalling) and there are well known cases in which replaying the log is totally undesired,... ranging from when you doing forensics on such devices to rescue measurements, where replaying a broken log might cause even more damage. 2) Even if it wouldn't potentially cause data corruptions, ro mounting, AFAIU still may lead to changes one may not want (e.g. last mount time and other meta-data). Things which, AFAIU, grub's mount doesn't do (at least that's what it claims). 3) And possibly even more problematic and also the reason why I mark this as "causes serious data loss" In the code the block device seems to be set read only... (ro_partition "$boottomnt") WTF?! No only doesn't the check a few lines before, whether the device is mounted, guarantee that it's still not rw-mounted a few lines later... but mounted isn't the only way the underlying block device may be used/modified. The first thing that pops to my mind is a filesystem repair in operation, which may easily end up the fs in a even worse state when interrupted. Or what about devices exported via nbd? I hope I didn't miss anything, which would protect against the above issues, but I didn't want to simulate such problems as I'm a bit too concerned about my data :) Cheers, Chris.
