Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp2091171rdb; Thu, 7 Dec 2023 19:17:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IHjMoMBuy3CCH2G1+jyZE8/zUIjdZ512L2TZKI3IaRk6yTW3/ZQ0niMm6QJkArCtl05xtqp X-Received: by 2002:a05:6a00:4088:b0:6ce:5353:20b with SMTP id bw8-20020a056a00408800b006ce5353020bmr4174936pfb.48.1702005438822; Thu, 07 Dec 2023 19:17:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702005438; cv=none; d=google.com; s=arc-20160816; b=I3vFTiNp0KizCh5JF07ErZXODHsmikYickdbOeMTIIu5o7Ho1+AvoU9yuKrleRpN9r 3LpK/A6FxLlb13Ek/7qu5RqQvIFyRubYGA0/Tmz8yfiXW2hlhGb4Wj9/Pkpl4DBjHE95 q+uQfAdYHgJ//UAUFF2mMXiawaQFkuFfyk7bLyOnpWPEpkdHDw0gJeIVxY9ryzZkNzjm Z0XuhHmLnTJvAKp1trjsjlstnRRyzUvydRcDDeL4i6zQYYQT9QiFR0DN9aA6nBYvbfvE w1N/u8+tu5YaYDlxLnE3rM7SvqCM7GwL2x1RRz8fd9GzNtSyYhla3EpvMs0XBpzZOYul cxqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=9Rux8vsdKkM8nJouugwOO5GuiDS1SIZxc5Vu7ejUgpg=; fh=m3UTn/R8kfnNRIQcdKQOLGnW/Euzb53iVotb88PNado=; b=PdAg+sA04KaoK4r3WaDZNuClrIVTm+8iE2qCaiz0GGGA+2ynOJvz1/HVEIhqyozbrs Zp4zQd4xx9QpUd2t1371knhozbG7ttc8NfPfjG2xxWwesdalfiRwJANsTMpoKQo+B1Yd QFNQgkc5vwec7Bq8A3AYySWbCv527x2MDWnfY27+Bd5czTZW8h5jTPnXKGqnlg4OrKtH 8XO+Yv55ccLyM+BMjKaj82m9cMCllh3F/W24oGzankvkd3lpA6JIPFLgkTbWNlp4URhF 6QbW6rzUqbuUZk9I+7Lhh6mxTPgESg+aBKnY7cml7QDv0YFcFiSBVl7PMYc3zYZ1d9Fo K+gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=kiokj3Cv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id q19-20020a056a00151300b006ce0c17d7d6si791168pfu.90.2023.12.07.19.17.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 19:17:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=kiokj3Cv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 686F2836B4D5; Thu, 7 Dec 2023 19:17:16 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1573050AbjLHDQy (ORCPT + 99 others); Thu, 7 Dec 2023 22:16:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235546AbjLHDQx (ORCPT ); Thu, 7 Dec 2023 22:16:53 -0500 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DD52171D for ; Thu, 7 Dec 2023 19:16:58 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6ce4fe4ed18so204943b3a.1 for ; Thu, 07 Dec 2023 19:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1702005417; x=1702610217; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9Rux8vsdKkM8nJouugwOO5GuiDS1SIZxc5Vu7ejUgpg=; b=kiokj3Cvkjuh6K6kaPMkRewYJfU3w76aX5w5wmeAVRKVmf0fG63b8As81aqJwLS8Ym /NU6pPAj7qvc6Y6z+bqUiMdUlNb63WQoULePOTxhnrIzSm3pWwUXUuZ47feGpdANRy6l d6Rm0Ahj2pUFGrINR3AJ4gSgcKopIg4zHVw+YSondoXswF1Ghn1Ro7Ay/5apnjwA0iWR avJmPk39lMK9S2+rEg5cP659n/hVbyR7phdrDxZAUm7Q/nH5x8YbwR5EDbZNtEXMIvRO fjD1db9u7IcdSj3hZxJKAcBmOXrDWE89NO7iSgk6DSN6xrfPkNyPb1v3Z5dyaOAXWzL5 /x1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702005417; x=1702610217; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9Rux8vsdKkM8nJouugwOO5GuiDS1SIZxc5Vu7ejUgpg=; b=sbAOULYQtyHI/mlJDzv8vvzLaODNalB2yYt0zJ9t14p52KiPCs1MAqVDYzXnkUBV/0 4wFJPqNhyjvc0R4IrX2s67ebEvqAeEnjMdCKJQZ/NABjbuplfkNj1rSn7EHaz8A/rJo1 AsBpOwSj0dXcKPxs1ATzH4jdEY05MxO/q3BmDvCIFX9UQSoXFQQtjblyJA+LhejKNpud FOwEIXA0iNTO8TK+gdtHS3swXcPhoSkvibRjshmiushdMbrOSTfs2Rgm7NeW/j11oNLm P+PW0ZwUWms4qOdsJWNwT69NvLWCzlQVP4cCSJgqr3+v1S/dsBGScPYxk6d4i7td8iH5 syug== X-Gm-Message-State: AOJu0YxXVcoEAH1jt0RiITwD8D6Bc5jAkKJcLJHTosbz1rsHu2yjheL2 JfBlXzW2QG7lXFGVJJCRVVQflQ== X-Received: by 2002:a05:6a00:194f:b0:6ce:2de2:fe4d with SMTP id s15-20020a056a00194f00b006ce2de2fe4dmr7543886pfk.1.1702005417512; Thu, 07 Dec 2023 19:16:57 -0800 (PST) Received: from [192.168.1.150] ([198.8.77.194]) by smtp.gmail.com with ESMTPSA id w4-20020aa78584000000b006ce5c583c89sm532425pfn.15.2023.12.07.19.16.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Dec 2023 19:16:56 -0800 (PST) Message-ID: Date: Thu, 7 Dec 2023 20:16:55 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Content-Language: en-US To: Christian Brauner , Florian Weimer Cc: Mathieu Desnoyers , Tycho Andersen , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Jan Kara , linux-fsdevel@vger.kernel.org References: <20231130163946.277502-1-tycho@tycho.pizza> <874jh3t7e9.fsf@oldenburg.str.redhat.com> <87ttp3rprd.fsf@oldenburg.str.redhat.com> <20231207-entdecken-selektiert-d5ce6dca6a80@brauner> From: Jens Axboe In-Reply-To: <20231207-entdecken-selektiert-d5ce6dca6a80@brauner> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 07 Dec 2023 19:17:16 -0800 (PST) On 12/7/23 3:58 PM, Christian Brauner wrote: > [adjusting Cc as that's really a separate topic] > > On Thu, Nov 30, 2023 at 08:43:18PM +0100, Florian Weimer wrote: >> * Mathieu Desnoyers: >> >>>>> I'd like to offer a userspace API which allows safe stashing of >>>>> unreachable file descriptors on a service thread. > > Fwiw, systemd has a concept called the fdstore: > > https://systemd.io/FILE_DESCRIPTOR_STORE > > "The file descriptor store [...] allows services to upload during > runtime additional fds to the service manager that it shall keep on its > behalf. File descriptors are passed back to the service on subsequent > activations, the same way as any socket activation fds are passed. > > [...] > > The primary use-case of this logic is to permit services to restart > seamlessly (for example to update them to a newer version), without > losing execution context, dropping pinned resources, terminating > established connections or even just momentarily losing connectivity. In > fact, as the file descriptors can be uploaded freely at any time during > the service runtime, this can even be used to implement services that > robustly handle abnormal termination and can recover from that without > losing pinned resources." > >> >>>> By "safe" here do you mean not accessible via pidfd_getfd()? >> >> No, unreachable by close/close_range/dup2/dup3. I expect we can do an >> intra-process transfer using /proc, but I'm hoping for something nicer. > > File descriptors are reachable for all processes/threads that share a > file descriptor table. Changing that means breaking core userspace > assumptions about how file descriptors work. That's not going to happen > as far as I'm concerned. > > We may consider additional security_* hooks in close*() and dup*(). That > would allow you to utilize Landlock or BPF LSM to prevent file > descriptors from being closed or duplicated. pidfd_getfd() is already > blockable via security_file_receive(). > > In general, messing with fds in that way is really not a good idea. > > If you need something that awkward, then you should go all the way and > look at io_uring which basically has a separate fd-like handle called > "fixed files". > > Fixed file indexes are separate file-descriptor like handles that can > only be used from io_uring calls but not with the regular system call > interface. > > IOW, you can refer to a file using an io_uring fixed index. The index to > use can be chosen by userspace and can't be used with any regular > fd-based system calls. > > The io_uring fd itself can be made a fixed file itself > > The only thing missing would be to turn an io_uring fixed file back into > a regular file descriptor. That could probably be done by using > receive_fd() and then installing that fd back into the caller's file > descriptor table. But that would require an io_uring patch. FWIW, since it was very trivial, I posted an rfc/test patch for just that with a test case. It's here: https://lore.kernel.org/io-uring/df0e24ff-f3a0-4818-8282-2a4e03b7b5a6@kernel.dk/ -- Jens Axboe