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 B5128C433E1 for ; Tue, 16 Jun 2020 15:43:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9BB9A21475 for ; Tue, 16 Jun 2020 15:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592322189; bh=6qGzqDRgQtxS+q1RhS4XN3NgSBMUArCOh0uuf57KmI4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=hc0LnnlY2AlNF91zZxZOPZfdlnvX8fQXc1np0JSsEMDOXcVSd4dZslzCQt3MrkFca H4rIlCss9xKsnaGz7jb4Tz+BdkjrL3maU/GXgcjK/ZMLS4p6RZHWXLWzyXDslSMi3F +VYs3GjbQVGfjygI5Jyh1WAvD2YaToBYnEBsb7eI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731014AbgFPPnE (ORCPT ); Tue, 16 Jun 2020 11:43:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:60168 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731713AbgFPPnD (ORCPT ); Tue, 16 Jun 2020 11:43:03 -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 1E9A8208E4; Tue, 16 Jun 2020 15:43:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592322182; bh=6qGzqDRgQtxS+q1RhS4XN3NgSBMUArCOh0uuf57KmI4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WBvsozOsNwxH7zhjRee1wZ+XZVZ7Z/uT3EL3TwiDHhkzBv0r1pm0uW1gsVJc3Upx9 cjcM1z/Wy7Jb/izB0+gRkRxFWK1DLSNDC1cKJA/vUZ7JKH3/yFq9KbZRTX6KkbCwCS KvUZRi84ZiLJ5yj1OWDzjOWLMnfK2k10PVOE1xR4= 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.7 033/163] aio: fix async fsync creds Date: Tue, 16 Jun 2020 17:33:27 +0200 Message-Id: <20200616153108.456489455@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200616153106.849127260@linuxfoundation.org> References: <20200616153106.849127260@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@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);