On Tue, Aug 02, 2022 at 06:21:56PM +1000, Daniel Ng wrote: > Hi, > > I've run into an issue when trying to use fsck with an ext4 image when > it has '=' in its name. > > Repro steps: > 1. fallocate -l 1G test=.img > 2. mkfs.ext4 test=.img > 3. fsck test=.img > > Response: > 'fsck.ext4: Unable to resolve '<path>/test=.img' > > Expected: > fsck to do it's thing. > > Observations: > Originally I wasn't sure what the source was, I thought that maybe > mkfs wasn't creating the image appropriately. > However, I've tried: > - renaming the image > - creating a hard-link to the image > > Running fsck on either the renamed image, or the hard-link, works as expected. > > Kernel version: Linux version 4.19.251-13516-ga0bcf8d80077 > Environment: Running on a Chromebook > > Kind regards, > Daniel Hi Daniel, yeah, that's a good catch. The problem is that various e2fsprogs tools (at least tune2fs and e2fsck) are using blkid_get_devname() to get the device name without ever checking if we already got the actual existing device name. The reason to call blkid_get_devname() at all is to get device in the form of NAME=value (like for example UUID=uuid, or LABEL=volume-label). However if we blindly pass in the device (or in this case regular file) name with an equal sign in it, the blkid_get_devname just returns whatever it can find by that tag. Which is likely nothing. Unless of course, you're trying to use e2fsck, or tune2fs on a file with an actual filename LABEL=volume-label and you have actual file system with 'volume-label' LABEL ;) That's a problematic behavior and depending on how we go about fixing it it could be potentialy exploitable... Maybe something like this: 1. look for the actual block device first 2. if none is found call blkid_get_devname() 3. if that didn't return anything maybe see if have a regular file and work with that 4. if we still get nothing, then we're "Unable to resolve..." Thoughts? -Lukas
