Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221016170046.171936-1-work.viveris@nightmared.fr>
In-Reply-To: <20221016170046.171936-1-work.viveris@nightmared.fr>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Mon, 7 Nov 2022 14:29:29 +0100
Message-ID: <CAJfpegspZ5UJJQZNi6Rdn6wPDfoZE6REFJ-XXX3sebhrHnQ=uw@mail.gmail.com>
Subject: Re: [PATCH] fuse: enable unprivileged mounts for fuseblk
To:     Simon Thoby <work.viveris@nightmared.fr>
Cc:     CONZELMANN Francois <Francois.CONZELMANN@viveris.fr>,
        "Eric W . Biederman" <ebiederm@xmission.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, 16 Oct 2022 at 19:00, Simon Thoby <work.viveris@nightmared.fr> wrote:
>
> Commit 4ad769f3c346ec3d458e255548dec26ca5284cf6 ("fuse: Allow fully
> unprivileged mounts") enabled mounting filesystems with the 'fuse' type for
> any user with CAP_SYS_ADMIN inside their respective user namespace, but did
> not do so for the 'fuseblk' filesystem type.
>
> Some FUSE filesystems implementations - like ntfs-3g - prefer using
> 'fuseblk' over 'fuse', which imply unprivileged users could not use these
> tools - in their "out-of-the-box" configuration, as these tools can always
> be patched to use the 'fuse' filesystem type to circumvent the problem.
>
> Enable unprivileged mounts for the 'fuseblk' type, thus uniformizing the
> behavior of the two FUSE filesystem types.
>
> Signed-off-by: Simon Thoby <work.viveris@nightmared.fr>

NAK in this form.

Please look at all the places where there's a difference between the
fuse and the fuseblk behavior and give proof that they won't result in
a security issue in case fuseblk is mounted unprivileged.

As a possibly much better alternative, try modifying the ntfs-3g code
to be able to work using the "fuse" fs type as well.

Thanks,
Miklos

fuseblk enables synchronouse RELEASE and DESTROY requests that are
unsuitable for unprivileged operation.


Thanks,
Miklos