Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1190497pxa; Sat, 22 Aug 2020 15:04:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx32t/IcHvKLWSyaaZ/wXPL5h0M2WPpV5A6n+QPv7f/3GquumMQFlki49YWBc5mqCUNmaqp X-Received: by 2002:a17:906:dbd2:: with SMTP id yc18mr8657139ejb.394.1598133868835; Sat, 22 Aug 2020 15:04:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598133868; cv=none; d=google.com; s=arc-20160816; b=QldFptfDsGPnG7TOroNUJf4yvnryZjEscIRLXis+yksP3OaCWVvbsYMSGIXQUmylb6 lZT8d3m9zO8YcmuCO7HDYyC8mbu/GxHM1WmdijE40iaisRTzf78eEYpe1Jx7iCVZfO9B j4Ly1w0PQ5MbwNoJuMNQnfcAgzo9A3ik6wi677T9Ag6yluOH1WOwpJmfXx9tNAYOu5L0 gOvkK21nKTLzyN49NPSY9g5WOoTkQdqZhPBxFe7ITitOXTiUK1KMZxRHTaZLZmNxclfI 3PfX9AOMPUqv95cg8rZDDYHksnd1kOjlF8J34mh142dO37SqDh3o0o+IeNg/96ECe7Q3 jk2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=DpLcrWMcjysc0FKXGOxzqR7zQkdO+CIQv21rXn1ITkY=; b=XA4R4QUC9icz6pUF96xP73D84XWf+PSFCgp9n2HP4T2pv5v/c50D/0+jUjKCd0gzbY SQP30OTEtBGbPEsGLSkFAEhJ7qYL06/DfijuXGZl7njp/sKcKRTt03cnr/JP4LCHMely eu0xnNCRGi6VtJrlkCe2FLz5cA5wq64k5w/8IEPm2QTxeKqo2ChQuaKiH58mx1dQfgxm t/6+tJqlEALqaZCB7c/TOyZuGG4KT06ZgMCchvtOLJYBFRsuLfFtbEbY6LyJWefeLuMy pv3sBgK3Ncg1K+yQiNK49qO2lm6DhHYWbrENUO5xdaJStlyKDfKiDnCeCpiFHohdC0P2 6p+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si3797361edr.534.2020.08.22.15.04.05; Sat, 22 Aug 2020 15:04:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728531AbgHVVBo (ORCPT + 99 others); Sat, 22 Aug 2020 17:01:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727005AbgHVVBn (ORCPT ); Sat, 22 Aug 2020 17:01:43 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24E7FC061573; Sat, 22 Aug 2020 14:01:43 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id EA91E12767ECE; Sat, 22 Aug 2020 13:44:55 -0700 (PDT) Date: Sat, 22 Aug 2020 14:01:41 -0700 (PDT) Message-Id: <20200822.140141.880909883327091452.davem@davemloft.net> To: kalou@tfz.net Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, netdev@vger.kernel.org, kuba@kernel.org, akpm@linux-foundation.org, adobriyan@gmail.com, viro@zeniv.linux.org.uk Subject: Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION From: David Miller In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sat, 22 Aug 2020 13:44:56 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Pascal Bouchareine Date: Sat, 22 Aug 2020 13:53:03 -0700 > On Sat, Aug 22, 2020 at 1:19 PM Pascal Bouchareine wrote: >> >> On Sat, Aug 22, 2020 at 12:59 PM Pascal Bouchareine wrote: >> >> > Would it make sense to also make UDIAG_SHOW_NAME use sk_description? >> > (And keep the existing change - setsockopt + show_fd_info via >> > /proc/.../fdinfo/..) >> >> >> Ah,very wrong example - to be more precise, I suppose that'd be adding >> a couple idiag_ext for sk_description and pid if possible instead > > About the pid part - > On top of multiple pids to scan for a given socket, there's also the > security provided by /proc - I'm not sure what inet_diag does for that > So maybe users calling it will need to scan /proc for a long time anyway... > > Or is that doable? I'd like to kindly ask that you do more research into how this kind of information is advertised to the user using modern interfaces, and what kinds of permissions and checks are done for those. You are proposing a new UAPI for the Linux kernel, and with that comes some level of responsibility. Thank you.