ovl: reserve ability to reconfigure mount options with new mount api
authorChristian Brauner <brauner@kernel.org>
Tue, 20 Jun 2023 11:42:38 +0000 (13:42 +0200)
committerAmir Goldstein <amir73il@gmail.com>
Tue, 20 Jun 2023 15:28:07 +0000 (18:28 +0300)
commitceecc2d87f007f9fc34e847401282111c0c29786
tree2c4de785dd13437ba0d96035331680dbe6713a0c
parentb36a5780cb44a16d4384639740d87e08d4cee627
ovl: reserve ability to reconfigure mount options with new mount api

Using the old mount api to remount an overlayfs superblock via
mount(MS_REMOUNT) all mount options will be silently ignored. For
example, if you create an overlayfs mount:

        mount -t overlay overlay -o lowerdir=/mnt/a:/mnt/b,upperdir=/mnt/upper,workdir=/mnt/work /mnt/merged

and then issue a remount via:

        # force mount(8) to use mount(2)
        export LIBMOUNT_FORCE_MOUNT2=always
        mount -t overlay overlay -o remount,WOOTWOOT,lowerdir=/DOESNT-EXIST /mnt/merged

with completely nonsensical mount options whatsoever it will succeed
nonetheless. This prevents us from every changing any mount options we
might introduce in the future that could reasonably be changed during a
remount.

We don't need to carry this issue into the new mount api port. Similar
to FUSE we can use the fs_context::oldapi member to figure out that this
is a request coming through the legacy mount api. If we detect it we
continue silently ignoring all mount options.

But for the new mount api we simply report that mount options cannot
currently be changed. This will allow us to potentially alter mount
properties for new or even old properties. It any case, silently
ignoring everything is not something new apis should do.

Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
fs/overlayfs/super.c