Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2586671yba; Fri, 10 May 2019 14:30:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqyksjyt65/XuTFo4qWpZBeQVLRHCHSHYt85cyz5TCcSXhxn7DHCDRCz5B9qMqDyVqzg+uiE X-Received: by 2002:a17:902:ea:: with SMTP id a97mr16010299pla.158.1557523808248; Fri, 10 May 2019 14:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557523808; cv=none; d=google.com; s=arc-20160816; b=cHoIsWlZQZBKox7FHZlDia8zY0R4bs3jpmr8QVSurNC3/77lj8mhrjcSyoOKgj69VS jPWDddGz/Evyn2ltVIMJSJ7No26y4KJ/Qo5E1NDn46vtmvmJDefJYWQcUeAZFrKuA7VD kuqCK6P1GfLJv3CMRMxJdJhjpT2i796YQREKMSgwrFONECsov8FWTVBamQcJhYnN2Q7S ieXU9/iReULFBBpRoLf0jFzpgHGkARovYOJdbzcJm7j3QagKOdO2EumE01pHwVWhewtk y34zrthcWfjMMiMIPWRxTDJVHa+yVN5t+PBVRMH+tNJD518WGvwV/sNsZMdmsEfDoa0z VirA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ULvb6m5Ct7N+U+Hk+TL0VPodYz5yvNtcE2Pdidu8130=; b=nx0szqiE4snWW4e/DdJ/37QsF1I9GV/kJvJbU2zhsviYuMbvkUnDQl+WUR6yB6F6dA jYebIekDzxCQos0CZgJxP9f3nY3lD5zjwfqTF17d4sgl4JQ2HsPSuQ1WFHceDlof5YvS use93Ff4qLUTibQcev7QJ4CtyLQ7h/gY5EXq68/SDaqIdQ/s0Fr2qXv6toUb0KnZcTdz cYKuY1He3okwBrSecLS0dojPOnpkm6e/GoBrUfnPhixFesvnQGOLTFqwssHDIjzkltUW bytHIBNSYBmqyJd1CohtjmUEQITQpCBuPyjP+lld8uYL3X2n+Ctz11tusFrGwbsZfJbW CGVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="OpeS/e5y"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31si8794358plb.30.2019.05.10.14.29.52; Fri, 10 May 2019 14:30:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="OpeS/e5y"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728198AbfEJV2l (ORCPT + 99 others); Fri, 10 May 2019 17:28:41 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:41899 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728164AbfEJV2l (ORCPT ); Fri, 10 May 2019 17:28:41 -0400 Received: by mail-ed1-f67.google.com with SMTP id m4so6945380edd.8 for ; Fri, 10 May 2019 14:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ULvb6m5Ct7N+U+Hk+TL0VPodYz5yvNtcE2Pdidu8130=; b=OpeS/e5yAb8uvpLXYNqA6N1MI8D7JXLjmHyNft0qks+8R/zc45m3XbQH7ZLcDfretb NJx/g0yV7jox/sIORLwOrxO1a9CV1jZa4gZ98sX8gwy7R8ojzc6s0LmwQEN7UABbk8mb Fxhe8bCtYUg4ePrk9piZU6axZgBrTRfXt2Nca9QBNovg68zQtj8GUi/rd7SCaOGE7XQG maBuJVPgPv8M7/MFnTidvVHklN5G7hqvUjLYWauPMuQewufDa3+DR5c2bfu6JIzKNOi0 rmTdxIt5cPg9YEIjCngJ1xtbJ4MWbtHDYD1wkUYVwYJKhe+0vPHojo8IZxOQPW4XrFjy V9dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ULvb6m5Ct7N+U+Hk+TL0VPodYz5yvNtcE2Pdidu8130=; b=pHShoxzDhJ8OXX7XodRuEP6cxSVNQMahKI6ixSal9GsfdlfufdoXWokaztH5MDKlnr ic61Gm7zW+dAHqIyUybViqhZgSV2KhOg0PaKo2/VsImhyer8++7yCpvyuBmBGo1cIiSp NE4yOr5Cgfrdcfq9mZ9bcEre+2r9dbDJR8hFJ6Gh6875sax6WTtbhWCwJVkUveHDxxoU 4KyTIdfO6H6J1HE4H4hepaPgJf7ySfypnIKCkff1tklE3LlvPNirC+IqDR+pGx6bJ7tI 6EIQ2rF6RgZybEEkuwBQMDqYfIRDe5xpMnr9Nq1OHAFX+sp0ODesvDeO2hMQaN29Dhhz g0nw== X-Gm-Message-State: APjAAAWyv//B72hRDir2a6lWSr4y67xzQGPr2SY6C/xm5JI5rmTo3KT6 bLTaGo2yrys36hdOGQG1pGgU6g== X-Received: by 2002:a50:f5d0:: with SMTP id x16mr13446339edm.287.1557523718509; Fri, 10 May 2019 14:28:38 -0700 (PDT) Received: from google.com ([2a00:79e0:1b:201:ee0a:cce3:df40:3ac5]) by smtp.gmail.com with ESMTPSA id c6sm1742858edk.81.2019.05.10.14.28.36 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 10 May 2019 14:28:37 -0700 (PDT) Date: Fri, 10 May 2019 23:28:31 +0200 From: Jann Horn To: Roberto Sassu Cc: viro@zeniv.linux.org.uk, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, initramfs@vger.kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com, silviu.vlasceanu@huawei.com, dmitry.kasatkin@huawei.com, takondra@cisco.com, kamensky@cisco.com, hpa@zytor.com, arnd@arndb.de, rob@landley.net, james.w.mcmechan@gmail.com Subject: Re: [PATCH v2 1/3] fs: add ksys_lsetxattr() wrapper Message-ID: <20190510212831.GD253532@google.com> References: <20190509112420.15671-1-roberto.sassu@huawei.com> <20190509112420.15671-2-roberto.sassu@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190509112420.15671-2-roberto.sassu@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 09, 2019 at 01:24:18PM +0200, Roberto Sassu wrote: > Similarly to commit 03450e271a16 ("fs: add ksys_fchmod() and do_fchmodat() > helpers and ksys_chmod() wrapper; remove in-kernel calls to syscall"), this > patch introduces the ksys_lsetxattr() helper to avoid in-kernel calls to > the sys_lsetxattr() syscall. > > Signed-off-by: Roberto Sassu [...] > +int ksys_lsetxattr(const char __user *pathname, > + const char __user *name, const void __user *value, > + size_t size, int flags) > +{ > + return path_setxattr(pathname, name, value, size, flags, 0); > +} Instead of exposing ksys_lsetxattr(), wouldn't it be cleaner to use kern_path() and vfs_setxattr(), or something like that? Otherwise you're adding more code that has to cast between kernel and user pointers.