From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1989EC433E0 for ; Tue, 16 Jun 2020 15:50:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC01021527 for ; Tue, 16 Jun 2020 15:50:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592322653; bh=6qGzqDRgQtxS+q1RhS4XN3NgSBMUArCOh0uuf57KmI4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=jgRVXcyl8v40+p6+s81XhyaEYTDhCHiRRY4u3e/zga7feXRD1dDKyAgUU7OVQ+Oy4 9EQT9tjay6bhMWRGmFIJRNPj0zl3zMsUk4YEWFDulnqoBfZEpXKmd3fztHLwJxdjgd jOfP1/vvytSg4Fub7Q1ldhORGQeNvxjTOqHjjKzg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731861AbgFPPuu (ORCPT ); Tue, 16 Jun 2020 11:50:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:46594 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732609AbgFPPui (ORCPT ); Tue, 16 Jun 2020 11:50:38 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 39B6C207C4; Tue, 16 Jun 2020 15:50:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592322637; bh=6qGzqDRgQtxS+q1RhS4XN3NgSBMUArCOh0uuf57KmI4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=n53PsdFXQIAf5BGd9h3FGv7vVu+U2HkZAzteTvxs1EVUI+DrzWfEUhJjrB1SOtW3Z Q9dMJzNLnpY2v92DqjyGIQ5ofvrV+ruZw6fTqexcaoNv4P87kcP4R0BkWN27ZR9O5W c+AzRN6BudjKkcSQZifzwq3kuJCnOQCEjLDOF0nI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Avi Kivity , Giuseppe Scrivano , Miklos Szeredi , Christoph Hellwig Subject: [PATCH 5.6 046/161] aio: fix async fsync creds Date: Tue, 16 Jun 2020 17:33:56 +0200 Message-Id: <20200616153108.561223868@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200616153106.402291280@linuxfoundation.org> References: <20200616153106.402291280@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Miklos Szeredi commit 530f32fc370fd1431ea9802dbc53ab5601dfccdb upstream. Avi Kivity reports that on fuse filesystems running in a user namespace asyncronous fsync fails with EOVERFLOW. The reason is that f_ops->fsync() is called with the creds of the kthread performing aio work instead of the creds of the process originally submitting IOCB_CMD_FSYNC. Fuse sends the creds of the caller in the request header and it needs to translate the uid and gid into the server's user namespace. Since the kthread is running in init_user_ns, the translation will fail and the operation returns an error. It can be argued that fsync doesn't actually need any creds, but just zeroing out those fields in the header (as with requests that currently don't take creds) is a backward compatibility risk. Instead of working around this issue in fuse, solve the core of the problem by calling the filesystem with the proper creds. Reported-by: Avi Kivity Tested-by: Giuseppe Scrivano Fixes: c9582eb0ff7d ("fuse: Fail all requests with invalid uids or gids") Cc: stable@vger.kernel.org # 4.18+ Signed-off-by: Miklos Szeredi Reviewed-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman --- fs/aio.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/fs/aio.c +++ b/fs/aio.c @@ -176,6 +176,7 @@ struct fsync_iocb { struct file *file; struct work_struct work; bool datasync; + struct cred *creds; }; struct poll_iocb { @@ -1589,8 +1590,11 @@ static int aio_write(struct kiocb *req, static void aio_fsync_work(struct work_struct *work) { struct aio_kiocb *iocb = container_of(work, struct aio_kiocb, fsync.work); + const struct cred *old_cred = override_creds(iocb->fsync.creds); iocb->ki_res.res = vfs_fsync(iocb->fsync.file, iocb->fsync.datasync); + revert_creds(old_cred); + put_cred(iocb->fsync.creds); iocb_put(iocb); } @@ -1604,6 +1608,10 @@ static int aio_fsync(struct fsync_iocb * if (unlikely(!req->file->f_op->fsync)) return -EINVAL; + req->creds = prepare_creds(); + if (!req->creds) + return -ENOMEM; + req->datasync = datasync; INIT_WORK(&req->work, aio_fsync_work); schedule_work(&req->work);