Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp955525iob; Fri, 13 May 2022 17:37:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJfxTZqGneeOMPZ4WhGq8AgxZNX/ealcvChRzrsUK0k9fvrU37IM74eJB/xLMjEjLdhXs4 X-Received: by 2002:a5d:6c68:0:b0:20c:7246:a86 with SMTP id r8-20020a5d6c68000000b0020c72460a86mr5752100wrz.283.1652488637930; Fri, 13 May 2022 17:37:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652488637; cv=none; d=google.com; s=arc-20160816; b=ONTLN7HUIJSGBASc7GeXjgoQOHU13qds3QVPB29PDDrB4+Sig0T87HT3WQvFKGIvED KYEVUzNrcQ3eNJ60AlX8m3nxE+ep7ZC99mcmUj1QeVANeHPF4HLDPWgkSiv1RuWZZrWp fIredlLSP5KMvrt9vHUy3hQqIC54zDMu0STJ4z6SRu5T+hYPOIBsQRJDhNVXbV4BGLen C9x47M9zR/yFRxjsFiUMQWv81y0XvBYjWmckXPqu3yJmN11a0F8G58LMFcMBtGN7osUo 615tJJhM57vdYlb4O0ix9I84teZCyVXT0JGe/oSOW9Eqa1ZM1F4HhNIJeW/k131NOkQ2 jwhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5/QaHzIsDx+VUbkQpyJdrmhr5ZThzTeQgKRfTCqVyP0=; b=R0MWpK6IoimDnOyXmB6cUxNOdzhJ+6siJU11UAXALkUEDTVjKt4QIck+9G1JT8kNFf USd+ej4Y4SYtgRxDNAapKvFiNdhj6a40V2chBene2YPV25hmr1sEHraqdw/YbTDqUYY0 ozI7lCFYKlLhZUNSh7ys5Ez5WOU9HooRlKFHHPVG9aV5HAavnoveMdzS3cy8dReXarLf /0MIT2ttq+WpL0OOcVjGREVElLOQAfrFik3S0pZnLRWdO65aLe/b2qJ8eEd/WP21gzIk +NBBNfNnSZ9V7yV8pjmgh9ZXua8nenKmplahRKqOvZ1gEpojlAR+vlVsG/Fnm9tlLzR4 2FfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=LoECVbfR; 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 bk17-20020a0560001d9100b0020ae0592f97si2918080wrb.861.2022.05.13.17.37.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 17:37:17 -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=LoECVbfR; 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 A781E33DDBC; Fri, 13 May 2022 16:27:52 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379183AbiEMJhE (ORCPT + 99 others); Fri, 13 May 2022 05:37:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379190AbiEMJg6 (ORCPT ); Fri, 13 May 2022 05:36:58 -0400 Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFFFC289BEA; Fri, 13 May 2022 02:36:56 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id c1so6628104qkf.13; Fri, 13 May 2022 02:36:56 -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; bh=5/QaHzIsDx+VUbkQpyJdrmhr5ZThzTeQgKRfTCqVyP0=; b=LoECVbfRBi4FDUjlO+TsWlNINlegPwvqwXrR2czl8byOnVKt85YnYW+sZhWjopmjyD cCBo/gmgUyl1Biu+wqDU2ZebY8KSUmnucMeRaz94Yxx9B2Qz8iwL8B6tIT3khC3iHhHH duozL9qSrIk2DZgTbNl9tXtu/aJhdNvROLmAVZ633A3MQ+mv9SoBoGjMUB1z8pgb+H6n g6NlEsKczLjIweg2IucLK3xCkZ6FivZse6yZ0kl2TWG6XO1oMwyKU/6W+lAEB8lhZib2 jvi+Yi9Jncwfl+APhDRIi7emZekDCYv5Ivd76x37C6N1or6FIPK3ElJk2Uri1gtt+HXD yAHQ== 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; bh=5/QaHzIsDx+VUbkQpyJdrmhr5ZThzTeQgKRfTCqVyP0=; b=0xQiaiAyLPFhNwWod9uS9GcVopo3bu/fNzILPMkMdmc2xB7ezEofeicQPBXGPsaeZp SdZE36ZVM7NAzoIKVF+4EgWVdzSj990pQGg4u3UJiaBo13WBjOsHCWh1RnGqKi4kQz9y cgTa45r/4elFT74DlzEe+RUSCYVNU9bSGScDi3Rsuc3LU4urKt+6l3RRojrwlX6M7rIK 6lTFNF6FkQo8flVsbidkDir8lfWBJRx1fv1sQN1a1LTCD1J70esnYx0oQylPoKdGggSP QOLE1yGaiIU7sf7fAQhTBVoh+6gkJ3B4B5OL5DwW0gwNOPHTLHCy9pAI0AvYS4wrft48 ZOdg== X-Gm-Message-State: AOAM532M6LJaN8M/hzB3uYB4xcWypQmYgy8PYyADscfsnIPXeMC2MARL X+DWH0JMv7qKgEpTOYMbFnM6RG0USe7sLIQvtIs7h+fUdy4= X-Received: by 2002:a05:620a:1aa0:b0:6a0:a34:15e0 with SMTP id bl32-20020a05620a1aa000b006a00a3415e0mr2940089qkb.19.1652434615582; Fri, 13 May 2022 02:36:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amir Goldstein Date: Fri, 13 May 2022 12:36:44 +0300 Message-ID: Subject: Re: procfs: open("/proc/self/fd/...") allows bypassing O_RDONLY To: Simon Ser Cc: "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" 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 Thu, May 12, 2022 at 3:38 PM Simon Ser wrote: > > On Thursday, May 12th, 2022 at 14:30, Amir Goldstein wrote: > > > Clients can also readlink("/proc/self/fd/") to get the path of the file > > and open it from its path (if path is accessible in their mount namespace). > > What the compositor does is: > > - shm_open with O_RDWR > - Write the kyeboard keymap > - shm_open again the same file with O_RDONLY > - shm_unlink > - Send the O_RDONLY FD to clients > > Thus, the file doesn't exist anymore when clients get the FD. From system POV, a readonly bind mount of /dev/shm could be created (e.g. at /dev/shm-ro) and then wayland could open the shm rdonly file from that path. If wayland cannot rely on system to create the bind mount for it, it could also clone its own mount namespace and create the bind mount in its own namespace for opening the rdonly file. But that implementation would be Linux specific an Linux has many other APIs that were suggested on the linked gitlab issue. You did not mention them in your question and did not say why those solutions are not a good enough for your needs. Thanks, Amir.