LintabOS 0.3.15

LintabOS 0.3.15 (pre-release)

The actual bug behind "the picker just isn't there" in LinWinMod - the deepest one yet in this run of real-hardware
fixes, and a real gap between this project's stated design intent and what the code actually did.

What was found

LinWinMod's disk scan is deliberately unprivileged - "it's read-only, so it shouldn't need a password just to
open the app." But disks.read_disk() has always read the partition table via sfdisk -J, which opens the raw
block device directly. On a real Duet 3, /dev/nvme0n1 is root:disk, mode 660 - a plain desktop user isn't in
the disk group (correctly: that group grants raw read+write to the whole disk, bypassing every filesystem
permission, including on Windows' own SAM hive). So every unprivileged call to read_disk() silently got zero
partitions back - not an error, just an empty list, because the existing code already treated an unreadable
partition table as "blank disk, no partition table yet." Both the automatic Windows-partition search and the
manual "pick any NTFS partition" picker depend on this, so both silently found nothing: no error message, no
partition list, nothing - "the picker just isn't there."

What this is not: adding the user to the disk group. That was floated and set aside - it grants raw
read+write to the entire disk indefinitely, which is a far bigger, standing privilege escalation than this needed,
and specifically defeats LinWinMod's own SAM/SECURITY read refusal by making it trivial to read those bytes
directly off the device instead.

The actual fix: lsblk already reads partition type GUIDs, UUIDs, GPT partition names, filesystem type and
label entirely through sysfs and the udev database - confirmed live, genuinely unprivileged, no elevation at all.
read_disk() now falls back to lsblk's own columns only when sfdisk cannot open the device at all. The
existing sfdisk-based path - what every privileged caller (the partitioner, the installer, Remove LintabOS)
already uses - is completely unchanged, specifically because lsblk's udev-sourced columns can lag right after a
partition table is freshly written (confirmed live: a udev race, not a timing bug in this fix - a brand new
partition can show null for its type for a moment even after the kernel already knows about it), which matters
to a tool that just wrote the table and immediately wants to read it back, but never to LinWinMod's scan, since
by the time anyone looks at an already-installed tablet, the partitions have existed since installation and udev
settled long ago. The one thing the fallback can't provide is each partition's start offset - deliberately: a
wrong sector/byte conversion there could silently miscalculate free space on a 4Kn drive, and nothing unprivileged
actually needs it.

Confirmed live end to end: list_microsoft_data_partitions() now returns both Windows partitions with zero
elevation, which means LinWinMod's manual picker - the actual UI the user was missing - now appears and is
populated correctly. (Automatic detection alone still won't complete unprivileged, since confirming a partition is
really Windows means mounting it to look for \Windows\System32 - a separate, correctly-still-privileged step
this was never trying to remove. The manual picker existed specifically to be the fallback for exactly that case,
and now it's the fallback that actually works.)

Files: lintabos-core_0.3.15_all.deb + .minisig, SHA256SUMS.