On 12/10/24 6:16 AM, Karel Zak wrote: > On Tue, Dec 10, 2024 at 12:11:49AM GMT, Demi Marie Obenour wrote: >> On 12/9/24 5:26 AM, Karel Zak wrote: >>> >>> Hi Demi, >>> >>> On Sat, Dec 07, 2024 at 08:45:32PM GMT, Demi Marie Obenour wrote: >>>> Is there a guarantee that if all data before the filesystem superblock is >>>> zero, and that the filesystem never writes to this region, libblkid (and >>>> thus, presumably, mount(8)) will always mount the filesystem with the >>>> correct filesystem type, even if e.g. someone writes a file containing >>>> a superblock of a different filesystem and the filesystem happens to put >>>> it where that superblock is valid? >>> >>> the libblkid library offers multiple modes, with "safe mode" being the >>> default for detecting filesystems. In this mode, the library checks >>> for any additional valid superblocks on the device. There are >>> exceptions for certain filesystems on CD/DVD media (such as udf and >>> iso), but for regular filesystems, sharing the same device is not >>> allowed. >>> >>> There is also an option to specify that a superblock is only valid if >>> no other area is using it (using blkid_probe_set_wiper() and >>> blkid_probe_use_wiper()). However, this is only used for LVM and >>> bcache. >>> >>> The library does not require that there are zeros before the >>> superblock, as not all mkfs-like programs zero out all areas. >>> >>> In recent years, there have been no reports of collisions. In the >>> entire history of the library, the only collisions I can recall are >>> with swap areas and luks, and occasionally with poorly detected FAT >>> filesystems (due to the messy design of FAT). >> >> Was https://github.com/util-linux/util-linux/issues/1305 a >> collision between ZFS and ext4? > > Yes, but in this case, ZFS was incorrectly detected. As you can see > from the bug report, blkid ended with an "ambiguous result" error. Should blkid instead stop at the first valid superblock when probing filesystems for mounting? >>> I believe the situation would be the same even without the >>> Discoverable Partition Specification. The kernel always divides the >>> whole disk into partitions, and libblkid/mount utilizes these >>> partitions. Therefore, the filesystems are automatically separated by >>> the partition table. >> >> /etc/fstab provides an explicit filesystem type. The Discoverable >> Partition Specification doesn't. > > You can use the "auto" file system type in fstab. It is also common > for people to not use the "-t <type>" option on the mount(8) command > line. > > However, if you are paranoid, then specifying the file system type in > fstab and avoiding Discoverable Partitions is a good choice. Does that mean that Discoverable Partitions are a bad idea for any filesystem that is not read-only? Can you explain “if you are paranoid”? -- Sincerely, Demi Marie Obenour (she/her/hers)
