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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0DD9C32773 for ; Fri, 19 Aug 2022 20:28:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351376AbiHSU2L (ORCPT ); Fri, 19 Aug 2022 16:28:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351462AbiHSU2I (ORCPT ); Fri, 19 Aug 2022 16:28:08 -0400 Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DFD410E793; Fri, 19 Aug 2022 13:28:02 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id h19so2204496uan.9; Fri, 19 Aug 2022 13:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=OYthYYNdZQvrpatlOm3lNYVTS6uAKNPx96c7Q90Mz3s=; b=hq3zLC3QBeifttKK3V6vCbMEkU8j6p1Z5SjX9GufXXA60CpcuyEALJ7vWrDpFTTPtb +HFPq1l8z9lFAFMrw+tl8qwiAGQVsf+eGbr2QjNgfhPAo/EtpksMB3/16Imfs+4TTxSx l24ekTa+3H4V6mfQCuSkbSQsYUe+i7Q7JKumt7XeuoOZrou8BcPFOPkA+g/3qYs0nKQc c5XJLdNv/9uA7TGR3lAyVAYIy7PMSNrkNKcsZyQIg1S+sRUirUjLQqM7oZlWhYnxyf1x lYgYwZN20kn+lUsm/L1q9DDUxSjtXMD84kq7mmUhn4FaJm0kh/rrNP43Mm6BpTwqCf6y A1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=OYthYYNdZQvrpatlOm3lNYVTS6uAKNPx96c7Q90Mz3s=; b=U7hbgUq2dVIeOyuXKUF2gZ3xlr6oaeTSJCo/f8mGHWPhBNFuGhYeAwlBtASYdPEK2Z 9uc1CEiay+AiE1B4wIe+K2jibaeCkvDfHAdSypD9DIF3TV8aB+ptnI50AhofDm35Yf1e zsrNfKmOVyfbHi6q1lvJCmySxastvIW2ldVZyjkE0oe7g+Q++c566EnjJprRy8mgNBS1 /fZvW/xv/j/ciHHLrP9MSbrNDnbf9m+wlV4cGu0IrL2NSMXjqNBWQB1Fqoq0B2/mCO7H l0itT+CeCT6nVa5sOaRlkT/il/dekiGlkEBcvEhwnmwM/OBBGsRJUxxFeRZcupu1XNm9 vE7w== X-Gm-Message-State: ACgBeo0USofOgc3JtoZ6kdyw5neucN9Ogy33H0s+WfB+TAEMar0jhzDF H/yoLg0eWmJdGiqHT1vs5J6EhCvn1usE4hcgYJA= X-Google-Smtp-Source: AA6agR76KQhgeaAZ++agDFZdUHr+Pui39KP1+A5o5aqlblLsaaVkQYVFKjPrRMaPphxedL00hKcBALuWLDkjiBYeks0= X-Received: by 2002:ab0:6dc5:0:b0:39b:fa5e:77f6 with SMTP id r5-20020ab06dc5000000b0039bfa5e77f6mr2860032uaf.114.1660940880665; Fri, 19 Aug 2022 13:28:00 -0700 (PDT) MIME-Version: 1.0 References: <20220607153139.35588-1-cgzones@googlemail.com> <20220608112728.b4xrdppxqmyqmtwf@wittgenstein> <20220608124808.uylo5lntzfgxxmns@wittgenstein> <20220618031805.nmgiuapuqeblm3ba@senku> <20220620060741.3clikqadotq2p5ja@senku> <20220622025715.upflevvao3ttaekj@senku> In-Reply-To: From: Amir Goldstein Date: Fri, 19 Aug 2022 23:27:49 +0300 Message-ID: Subject: Re: [RFC PATCH] f*xattr: allow O_PATH descriptors To: =?UTF-8?Q?Christian_G=C3=B6ttsche?= Cc: Aleksa Sarai , Christian Brauner , SElinux list , Miklos Szeredi , Linux API , linux-man , Alexander Viro , linux-fsdevel , linux-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Fri, Aug 19, 2022 at 9:05 PM Christian G=C3=B6ttsche wrote: > > On Wed, 22 Jun 2022 at 04:57, Aleksa Sarai wrote: > > > > On 2022-06-20, Amir Goldstein wrote: > > > To be a reasonable reaction to the currently broken API is > > > to either accept the patch as is or request that setxattrat() > > > will be added to provide the new functionality. > > > > Since the current functionality cannot be retroactively disabled as it > > is being used already through /proc/self/fd/$n, adding > > *xattrat(AT_EMPTY_PATH) doesn't really change what is currently possibl= e > > by userspace. > > > > I would say we should add *xattrat(2) and then we can add an upgrade > > mask blocking it (and other operations) later. > > > > It seems setxattrat() is the preferred way to continue. > fsetxattr() would have one advantage though (w.r.t. SELinux): > > The steps to label a file are: > 1. get the type of the file (via stat(2) family) > 2. lookup the desired label from the label database via selabel_lookup(= 3) > 3. assign the retrieved label to the file > > The label is sensitive to the file type, e.g. > > $ matchpathcon -m file /etc/shadow > /etc/shadow system_u:object_r:shadow_t:s0 > $ matchpathcon -m lnk_file /etc/shadow > /etc/shadow system_u:object_r:etc_t:s0 > > Using the *at() family the file type could change between step 1. and 3., > which operating on an O_PATH file descriptor would prevent. I don't understand the problem. If you have an O_PATH fd, the object it represents does not change. If you use fstatat(fd, ..., AT_EMPTY_PATH) (or fstat) and setxattrat(fd, ..., AT_EMPTY_PATH), it prevents the race. Thanks, Amir.