Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2289739iof; Wed, 8 Jun 2022 01:33:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOd4wudNFgnX8qLSW0Wq/93MZSBN+m1i+qy4Vduxc0C/48SMEIAKLLPNbzc7pgBqpH+dVl X-Received: by 2002:a63:4c:0:b0:3fa:b4d8:26cf with SMTP id 73-20020a63004c000000b003fab4d826cfmr28237452pga.463.1654677200009; Wed, 08 Jun 2022 01:33:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654677200; cv=none; d=google.com; s=arc-20160816; b=N4JSCdZLkqydeI0nKiCSYdeo/AjhtJuEMQI95cDpbKcX2LLu+I4M9Ryp2edlopvqHp I1gHBAlYivQz9i42noKmKTcfrwKbtLx8mvM7f6VZoU7xrmup57K6OM19GXDfptT0vL4N QbTZN0iLKcX/7RfEALJyd0dG/l+Ehadm1lofiuUgZI4l5E/6ZeAYocaPb+PEc5QMTX49 Hta5GHIw1bk7+gX4SFt1pgs5idmByujf2xlegVsBt0XF5TCTiyWhSnVabTBYNCWwkT++ bhwj2triHPzgc4At6Fio+Cpro2snpmnW7BXOg6VSJ8jpFqrgRpdGCfBED/y4sSWGkMx6 icAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=QBGwtKpyTYcwHawGkkLJIlVc8uYMzI2DXbLnehmXfbE=; b=mhL/LNDIROsM2ix5dsHNUnu4QEv1aDJgR3iZU45NOoU2OCXRfVvnb7sZDJV3BqSELN iyla8TfhOUaV5ef3UMt1JE3/gM6enuQyAAN5O/3TjYaZhu+W63tBZ2wIbFwVG787Hn3n mhzaKWI6WvaBeI96yA3vrtuyP0mb+6iwtzfa+NE7m5bIXw4FZFezFhQaY/kGaFbEG10+ /Zs47tEtGMZP3fkmAuflfunmWuYP74ZHYl6Xz0CVlc/K1jbJCwqnqZCr8CWK8JrePT29 5+mfJGpjPXdZBD5o1zGQ/geKtzlKZm9+A9/ICA3v+hNlBZsQ+YVc6byH+TnljfVfKXSz 2FzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=SB0WOTvP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id s1-20020a056a00178100b005107e713c1dsi20866947pfg.273.2022.06.08.01.33.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 01:33:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=SB0WOTvP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 10FDE1EA84B; Wed, 8 Jun 2022 01:00:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239644AbiFHHCQ (ORCPT + 99 others); Wed, 8 Jun 2022 03:02:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241477AbiFHGI0 (ORCPT ); Wed, 8 Jun 2022 02:08:26 -0400 Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B279417CD3; Tue, 7 Jun 2022 22:14:49 -0700 (PDT) Received: by mail-vs1-f51.google.com with SMTP id q14so18642885vsr.12; Tue, 07 Jun 2022 22:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QBGwtKpyTYcwHawGkkLJIlVc8uYMzI2DXbLnehmXfbE=; b=SB0WOTvPTBDL580CNJpBSrVLBNq9/eKKCK8hLOT6KVBVv0TrGp2zn/JM1IUJQw6u9G eK8IYj3exswHjhWEXQrSbAZHl8f5WSnJ6kfjSaI8FwZM4nJ8zOM+lwXCPaFkazROYF+R hyhMO1E8boquWtsici45GjRKvi9pPRiAar2Ozft3hQec274g2MwkIgoEJD1Y9bByBJJf FVbLqu7oDS75iva6nVklYe4zTkwweuUxGq+mWeccpUXcr+xwOEKkmVfMcRpVbOkClACN 5gYHGH9BHx2AY9PLsi+YeDZSFKy2I3p+HojZR8U2QLhLQ78UHqRbK+044hBz3mbTDBrB A1fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QBGwtKpyTYcwHawGkkLJIlVc8uYMzI2DXbLnehmXfbE=; b=vfjEH6tL6pGAbJyASqQG5WbS/Ag5XyyI7q5UeULH5sX9JE0sFjtJkH9jsoIvlVZCKh H+K2jVlrn7AyYTinmHpl1EZpYMQgp9uI1eBE27mVvnvxVIZTkoyZKE6RBKzcKNYQoW0Q oBgxAsW+4AAH9KMwdFAUpD+ScMS9DzPBCxnZYpNPLwUberHgU6Kj9hPw5kwCBWJoWCIw +MitgL7bwvT5yNNL+dIURoo+PHs75qmfUfbQlIotq7jixvPiAZ6GJMeJCuzVDdAgeBor AJ0wHreZEFFc+4vJCbFqxzYQ4OryTTPyjp5/OCo7mjzW5rROBydLilIYQXd/0n91pWos xTOg== X-Gm-Message-State: AOAM533uNSVOURNrmncryBxkn+g5cM8iCM2gyDhiRe/AUR4SO+fJPohb rdrkaIb68yT7TAMIeUrSeY8PmYuLprHG+MbxwYA= X-Received: by 2002:a67:70c4:0:b0:349:d442:f287 with SMTP id l187-20020a6770c4000000b00349d442f287mr15008426vsc.2.1654665199165; Tue, 07 Jun 2022 22:13:19 -0700 (PDT) MIME-Version: 1.0 References: <20220607153139.35588-1-cgzones@googlemail.com> In-Reply-To: <20220607153139.35588-1-cgzones@googlemail.com> From: Amir Goldstein Date: Wed, 8 Jun 2022 08:13:07 +0300 Message-ID: Subject: Re: [RFC PATCH] f*xattr: allow O_PATH descriptors To: =?UTF-8?Q?Christian_G=C3=B6ttsche?= Cc: selinux@vger.kernel.org, Miklos Szeredi , Linux API , linux-man , Alexander Viro , linux-fsdevel , linux-kernel , Alejandro Colomar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 8, 2022 at 5:23 AM Christian G=C3=B6ttsche wrote: > > From: Miklos Szeredi > > Support file descriptors obtained via O_PATH for extended attribute > operations. > > Extended attributes are for example used by SELinux for the security > context of file objects. To avoid time-of-check-time-of-use issues while > setting those contexts it is advisable to pin the file in question and > operate on a file descriptor instead of the path name. This can be > emulated in userspace via /proc/self/fd/NN [1] but requires a procfs, > which might not be mounted e.g. inside of chroots, see[2]. > > [1]: https://github.com/SELinuxProject/selinux/commit/7e979b56fd2cee28f64= 7376a7233d2ac2d12ca50 > [2]: https://github.com/SELinuxProject/selinux/commit/de285252a1801397306= 032e070793889c9466845 > > Original patch by Miklos Szeredi > https://patchwork.kernel.org/project/linux-fsdevel/patch/20200505095915.1= 1275-6-mszeredi@redhat.com/ > > > While this carries a minute risk of someone relying on the property of > > xattr syscalls rejecting O_PATH descriptors, it saves the trouble of > > introducing another set of syscalls. The bitter irony is that we now want to add another set of syscalls ;-) https://lore.kernel.org/linux-fsdevel/CAOQ4uxiqG-w8s+zRqk945UtJcE4u0zjPhSs= =3DMSYJ0jMLLjUTFg@mail.gmail.com/ > > > > Only file->f_path and file->f_inode are accessed in these functions. > > > > Current versions return EBADF, hence easy to detect the presense of > > this feature and fall back in case it's missing. > > CC: linux-api@vger.kernel.org > CC: linux-man@vger.kernel.org > Signed-off-by: Christian G=C3=B6ttsche I think it is important to inspect this with consistency of the UAPI in min= d. What I see is that fchdir(), fcntl(), fstat(), fstatat() already accept O_P= ATH so surely they behave the same w.r.t old kernels and EBADF. Those could all be better documented in their man pages. w.r.t permission checks, this is no different than what *xattr() variants already provide. Therefore, I see no reason to object to this UAPI change. You may add: Reviewed-by: Amir Goldstein Thanks, Amir. > --- > fs/xattr.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/fs/xattr.c b/fs/xattr.c > index e8dd03e4561e..16360ac4eb1b 100644 > --- a/fs/xattr.c > +++ b/fs/xattr.c > @@ -656,7 +656,7 @@ SYSCALL_DEFINE5(lsetxattr, const char __user *, pathn= ame, > SYSCALL_DEFINE5(fsetxattr, int, fd, const char __user *, name, > const void __user *,value, size_t, size, int, flags) > { > - struct fd f =3D fdget(fd); > + struct fd f =3D fdget_raw(fd); > int error =3D -EBADF; > > if (!f.file) > @@ -768,7 +768,7 @@ SYSCALL_DEFINE4(lgetxattr, const char __user *, pathn= ame, > SYSCALL_DEFINE4(fgetxattr, int, fd, const char __user *, name, > void __user *, value, size_t, size) > { > - struct fd f =3D fdget(fd); > + struct fd f =3D fdget_raw(fd); > ssize_t error =3D -EBADF; > > if (!f.file) > @@ -844,7 +844,7 @@ SYSCALL_DEFINE3(llistxattr, const char __user *, path= name, char __user *, list, > > SYSCALL_DEFINE3(flistxattr, int, fd, char __user *, list, size_t, size) > { > - struct fd f =3D fdget(fd); > + struct fd f =3D fdget_raw(fd); > ssize_t error =3D -EBADF; > > if (!f.file) > @@ -910,7 +910,7 @@ SYSCALL_DEFINE2(lremovexattr, const char __user *, pa= thname, > > SYSCALL_DEFINE2(fremovexattr, int, fd, const char __user *, name) > { > - struct fd f =3D fdget(fd); > + struct fd f =3D fdget_raw(fd); > int error =3D -EBADF; > > if (!f.file) > -- > 2.36.1 >