Received-SPF: pass (google.com: domain of linux-ext4+bounces-1592-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Luis Henriques <lhenriques@suse.de>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "Theodore Ts'o" <tytso@mit.edu>,  Andreas Dilger
 <adilger.kernel@dilger.ca>,  Alexander Viro <viro@zeniv.linux.org.uk>,
  Christian Brauner <brauner@kernel.org>,  Jan Kara <jack@suse.cz>,  Amir
 Goldstein <amir73il@gmail.com>,  linux-ext4@vger.kernel.org,
  linux-fsdevel@vger.kernel.org,  linux-unionfs@vger.kernel.org,
  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] ovl: fix the parsing of empty string mount
 parameters
In-Reply-To: <CAJfpeguN9nMJGJzx8sgwP=P9rJFVkYF5rVZOi_wNu7mj_jfBsA@mail.gmail.com>
	(Miklos Szeredi's message of "Mon, 11 Mar 2024 11:53:03 +0100")
References: <20240307160225.23841-1-lhenriques@suse.de>
	<20240307160225.23841-4-lhenriques@suse.de>
	<CAJfpegtQSi0GFzUEDqdeOAq7BN2KvDV8i3oBFvPOCKfJJOBd2g@mail.gmail.com>
	<87le6p6oqe.fsf@suse.de>
	<CAJfpeguN9nMJGJzx8sgwP=P9rJFVkYF5rVZOi_wNu7mj_jfBsA@mail.gmail.com>
Date: Mon, 11 Mar 2024 13:23:25 +0000
Message-ID: <87cys0x5pu.fsf@suse.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Miklos Szeredi <miklos@szeredi.hu> writes:

> On Mon, 11 Mar 2024 at 11:34, Luis Henriques <lhenriques@suse.de> wrote:
>>
>> Miklos Szeredi <miklos@szeredi.hu> writes:
>>
>> > On Thu, 7 Mar 2024 at 19:17, Luis Henriques <lhenriques@suse.de> wrote:
>> >>
>> >> This patch fixes the usage of mount parameters that are defined as st=
rings
>> >> but which can be empty.  Currently, only 'lowerdir' parameter is in t=
his
>> >> situation for overlayfs.  But since userspace can pass it in as 'flag'
>> >> type (when it doesn't have a value), the parsing will fail because a
>> >> 'string' type is assumed.
>> >
>> > I don't really get why allowing a flag value instead of an empty
>> > string value is fixing anything.
>> >
>> > It just makes the API more liberal, but for what gain?
>>
>> The point is that userspace may be passing this parameter as a flag and
>> not as a string.  I came across this issue with ext4, by doing something
>> as simple as:
>>
>>     mount -t ext4 -o usrjquota=3D /dev/sda1 /mnt/
>>
>> (actually, the trigger was fstest ext4/053)
>>
>> The above mount should succeed.  But it fails because 'usrjquota' is set
>> to a 'flag' type, not 'string'.
>
> The above looks like a misparsing, since the equals sign clearly
> indicates that this is not a flag.

No, not really.  The same thing happens without the '=3D':

mount -t ext4 -o usrjquota /dev/loop0p1 /mnt/=20
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0p1, mis=
sing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

The parsing code gets a FSCONFIG_SET_FLAG instead of FSCONFIG_SET_STRING.

>> Note that I couldn't find a way to reproduce the same issue in overlayfs
>> with this 'lowerdir' parameter.  But looking at the code the issue is
>> similar.
>
> In overlayfs the empty lowerdir parameter has a special meaning when
> lowerdirs are appended instead of parsed in one go.   As such it won't
> be used from /etc/fstab for example, as that would just result in a
> failed mount.
>
> I don't see a reason to allow it as a flag for overlayfs, since that
> just add ambiguity to the API.

Fine with me.  But it'd be nice to double-check (by testing) that when
overlayfs gets a 'lowerdir' without a value it really is doing what you'd
expect it to do.

Cheers,
--=20
Lu=C3=ADs