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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C3D5CF6D2C for ; Wed, 2 Oct 2024 13:45:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7B886B0327; Wed, 2 Oct 2024 09:45:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2E7B6B0329; Wed, 2 Oct 2024 09:45:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F4886B0328; Wed, 2 Oct 2024 09:45:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 76BD86B0326 for ; Wed, 2 Oct 2024 09:45:20 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1E84A1A0677 for ; Wed, 2 Oct 2024 13:45:20 +0000 (UTC) X-FDA: 82628784000.03.D37772F Received: from kawka3.in.waw.pl (kawka3.in.waw.pl [68.183.222.220]) by imf27.hostedemail.com (Postfix) with ESMTP id 09D374001C for ; Wed, 2 Oct 2024 13:45:17 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of zbyszek@in.waw.pl designates 68.183.222.220 as permitted sender) smtp.mailfrom=zbyszek@in.waw.pl; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727876653; a=rsa-sha256; cv=none; b=ARP47XpV65uNKoiX2ineFr7cYLQOXDxxVNTQsqe2JJfs81tFQkqPtoXzDnl8VctZcILoVn W4uUdtFSESvLYsaU+DU/frGqwCJIX9xR0RfJptztFzKVep2EfNrjpPi4Ji/t0K4I4cl/ce WYCkbDpIqgPNeB7p4KkSLqgeS78dN24= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of zbyszek@in.waw.pl designates 68.183.222.220 as permitted sender) smtp.mailfrom=zbyszek@in.waw.pl; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727876653; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=353yi7E14o/mL2iCWu1iQeo4ipMI7LIZpWmuSSZMTU8=; b=dvxCkHe25oLQStK4/l5eWSiOSpF3HTiwcjzZweFuOe6TEE418iZPi/GvvvKAcUTahsV+KV d80Ge8xeKnpJETk+gOtbxCaFiYWVjvXMMpzzVR7ye4nx/umH9c2hbrfsgg48/2R5cqpNYS MxeWfMFqK8zBhyQNu04nBzEUbKwpjJY= Received: by kawka3.in.waw.pl (Postfix, from userid 1000) id 925A0550CEB; Wed, 2 Oct 2024 13:45:15 +0000 (UTC) Date: Wed, 2 Oct 2024 13:45:15 +0000 From: Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= To: Tycho Andersen Cc: Aleksa Sarai , Alexander Viro , Christian Brauner , Jan Kara , Eric Biederman , Kees Cook , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Tycho Andersen Subject: Re: [PATCH v3 1/2] exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case Message-ID: References: <20241001134945.798662-1-tycho@tycho.pizza> <20241001.175124-western.preview.meager.saws-pzvpWxOhfokt@cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20241001.175124-western.preview.meager.saws-pzvpWxOhfokt@cyphar.com> X-Stat-Signature: s6tuxy7bqs3n954ufqthh4c579ijdnt6 X-Rspamd-Queue-Id: 09D374001C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727876717-915774 X-HE-Meta: U2FsdGVkX1/05E794OHi3vQiZ4ei4qJUbHc1ytESWCrjkhEJWON7GQhy94b8JVFIUrWtjtB5oIR1M3REdtzz/Vpl9HRWr7tij1sw4nD3CB62VNkW0VaA0zwKR6NJrU5oricjaD7k9fy3NBPUePT5+wnCqKV/nRGxRaBM2Z7fCdjegVp1dnbmYXuNPzOmCXcdJGDq7+VymrloP/AogI9yFBSJ0gINeod8K6BwDttf+ylQWpsE+HHbl/gP/0KqskCcoWbJrnBa3mRuuIctRwpgtdD0bDlkAJRoj1xcjkSltzjlnTliNVe86CmavMtnojgFqpYGYhMzuwjFOPl3WkFS69DFy1Utt4wwgdo8AiHmzbp2oUjLEIbk3ZNAvLuAfEy/g1KzADzOOCNTrVMM22/VTdz/2xJv9sNslUiUALFKmgb46767GxuQgGu8NV7STYRKr2I2FLCEMVv0WgatsgU33T0Hh2FUlt8ye95O/waNBQnXduBuBgbyChdkq4W+3QXpkW9IdaZxQuu1JCDPn5YZO/hq/aytCB9DVNL3jqmx7io/1Y5MY84NhqvwCZ4vM2vB9ewTar9wgnlj0cGd95TywC+1aFCUxvLPXgAJmKvmj9epWgD+8h6Jn0B/3fcyX1xIgEQKDpc/DTa7N0gTh8+RdOkG6T2f+71Ff24r+1/oungxb/A3XUhFW5/3mksjG7JWeA5Dluk71V9PoHf9fP8+T0iObM2uTM/bhA+dpdFgBc7NGo1vW2EejsSJBsgq0Qume4mtY1hegH30v3iAnu/HXVoDRVnL9sTP3XgSkGai0v/YvyQrLI7xRv94CYrt15th9LXGxq9oHINv7iTtJM6ABgUovjgAkDbOc4LvFPD/aBD+7df6TJLDYotApK1HVHQn5k8TsPxgBU09IGcU75AFRRnjxOiO/tjZyLDyLL29W0HU/px5h41bpLH+lQeEjgzut4ypQNaTxBv2Eun3l6e iwmS2DqY BGlIlyfMDqPMf7QDwpERU4yn97rKGP61gkOO13v8GWpkSXDpTsxQh99VbBSqVNa4iwpYyEHxClMN/GhlIVybfS8zvt9VMFC6lmobym5ivgWRRqhua0pqSmUv42kc0nqcqw3z40ypvyo8sY+nPgKp0RnodLwS6grXZVXXy+ELASyVJiDWrDNTVthWyXmk2a0DBpBazFZ7O5UsL+dvD9/Yq7G2ygAY/VOZCrzFHlxVh9f8YM6w= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Oct 01, 2024 at 08:42:56PM +0200, Aleksa Sarai wrote: > On 2024-10-01, Tycho Andersen wrote: > > From: Tycho Andersen > > > > Zbigniew mentioned at Linux Plumber's that systemd is interested in > > switching to execveat() for service execution, but can't, because the > > contents of /proc/pid/comm are the file descriptor which was used, > > instead of the path to the binary. This makes the output of tools like > > top and ps useless, especially in a world where most fds are opened > > CLOEXEC so the number is truly meaningless. > > > > Change exec path to fix up /proc/pid/comm in the case where we have > > allocated one of these synthetic paths in bprm_init(). This way the actual > > exec machinery is unchanged, but cosmetically the comm looks reasonable to > > admins investigating things. > > While I still think the argv[0] solution was semantically nicer, it > seems this is enough to fix the systemd problem for most cases and so we > can revisit the argv[0] discussion in another 10 years. :D Hi Tycho and everyone else, First, thank you so much for picking this up! Second, sorry for being late with a reply… Third, I tested the kernel with the patch and with systemd with the fexecve option enabled, and it all works as expected. Unfortunately, I don't think that the approach with f_path.dentry->d_name.name can be used :( As discussed previously, there are various places where symlinks are used. Alternatives and busybox were raised. Some additional examples: systemd (e.g. /usr/lib/systemd/systemd-udevd symlinks to /usr/bin/udevadm), yum-builddep, yum-config-manager, yumdownloader, yum-groups-manager all symlink to a multicall dnf-utils binary, and so on. The question is whether "pgrep" and similar tools not getting the expected name is a problem, and I think that the answer is, unfortunately, "yes". Users will notice this. As a distro maintainer, I would be _very_ wary of flipping this on in systemd, because there certainly are scripts and other tools that use that logic to check if things are running on the system. systemd uses cgroups and doesn't care about COMM at all, and I expect that many other modern tools won't either, but we have to take into account the long tail of local admin scripts and older tools. To avoid regressions and complaints, we really want an API that replaces the current execve invocations with an fd-based approach but doesn't change how things otherwise look. Arguably, the current patch would work great for 99% of cases, but that's not enough. (In particular, with rust being used more often for low level tools, and the binaries being large because of the static linking, I expect multicall binaries to become even more common. E.g. uutils-coreutils that might become the default coreutils implementation in a few years. It uses a multi-call binary and symlinks. Having 'coreutils' instead of 'sleep' as COMM is not good.) Please consider going back to the approach with argv[0]. Zbyszek > > v2: * drop the flag, everyone :) > > * change the rendered value to f_path.dentry->d_name.name instead of > > argv[0], Eric > > + __set_task_comm(me, bprm->file->f_path.dentry->d_name.name, true);