Re: Ensuring that mount(8) will always interpret a filesystem correctly

Demi Marie Obenour <[email protected]>
Newsgroups org.kernel.vger.util-linux
Message-ID <[email protected]>
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?

>> The motivation for this message is that systemd-gpt-generator generates
>> mountpoints based on Discoverable Partition Specification GUIDs.  These
>> indicate the mountpoint of the partition but not the filesystem type.
> 
> Filesystem auto-detection is a common feature. The situation is
> similar to having an "auto" fstype in fstab. The systemd-gpt-generator
> simply identifies the partition as "/usr" (or any other mountpoint)
> and the rest is usual scenario.> 
>> If a correctly-produced filesystem image will always continue to be
>> recognized as the correct type, this is fine.  Otherwise, an unlucky
>> combination of writes to the filesystem and filesystem allocation decisions
>> could cause the filesystem to start being mounted as the wrong type, which
>> would be very bad.  According to https://github.com/util-linux/util-linux/issues/1305,
>> libblkid can indeed probe for subsequent superblocks after the first one it
>> finds.
> 
> 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.