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 9D001CF9C6B for ; Tue, 24 Sep 2024 22:59:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30C676B009C; Tue, 24 Sep 2024 18:59:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 295876B009D; Tue, 24 Sep 2024 18:59:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E8356B00A2; Tue, 24 Sep 2024 18:59:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E0CAB6B009C for ; Tue, 24 Sep 2024 18:59:42 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 649AE140545 for ; Tue, 24 Sep 2024 22:59:42 +0000 (UTC) X-FDA: 82601150604.11.D52B978 Received: from fout-a2-smtp.messagingengine.com (fout-a2-smtp.messagingengine.com [103.168.172.145]) by imf11.hostedemail.com (Postfix) with ESMTP id 597CC40006 for ; Tue, 24 Sep 2024 22:59:40 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=tycho.pizza header.s=fm1 header.b=JLpmeHWo; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=naAS52CC; spf=pass (imf11.hostedemail.com: domain of tycho@tycho.pizza designates 103.168.172.145 as permitted sender) smtp.mailfrom=tycho@tycho.pizza; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727218719; a=rsa-sha256; cv=none; b=0R35aSK/TVhC3C8VPXZz4VmPxilpm6eiy+ukdkiZCl0OXPqKvW7H7deowg1+xm49NYx+Cc GQWYhCMFg6J5C7SB7pfUeRf485jpTjwr4F53vGWTn0PTXL/ccXSn4aPgwtl8If3gfGFNqi PURs/aa6YHUSa/pVvxBgijc0ybhijg0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=tycho.pizza header.s=fm1 header.b=JLpmeHWo; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=naAS52CC; spf=pass (imf11.hostedemail.com: domain of tycho@tycho.pizza designates 103.168.172.145 as permitted sender) smtp.mailfrom=tycho@tycho.pizza; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727218719; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=d8fUlRHE2iZfy80BDgU0TCA1aV71a21YfiFtM5egfSU=; b=q3/Q4okn+0mcdyBA3Vs6DtFl/w2fgW8v8+IOK8MJY2LvzwiOBXixDHVdAJpUTCOW7yAHs6 dWICgpDTzhgZKfHFzSsji8eyHAtOZDGsNUS1LY+wzK1/AN611VG7YtIvfKLOdKbvkuaQe6 AsxPXsn8iHXTKwWMuPdJO0OvrOUlPT8= Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 9B83213800F0; Tue, 24 Sep 2024 18:59:39 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Tue, 24 Sep 2024 18:59:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tycho.pizza; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1727218779; x=1727305179; bh=d8fUlRHE2i Zfy80BDgU0TCA1aV71a21YfiFtM5egfSU=; b=JLpmeHWoWH6kE+W42hBonNbqK1 MU6EglXwbTg8IylUGpH58l2TFkopHLmOPFMAie1iFzqJu/ht1OY8OWfw3yQ0gVu+ 7qUlC48O7QSk7YY79ZAyfRkAaxE4UXbJnb+ULC0XV16s/zzI2GVcYpoT35wQSqkI i59vcYcau6W1uz9nTOgQKZxP64Qs2BZqUVa+jtCiu8YcdWENBYKFLuxhq+awz06U oZPUmpB8MTb1Umkq4OIgtHpZSPP1iC1TGFeJP9Oz3TKbtQEtLQ9RKhGDdb9sj0de 6A+Z8Al2s2nKfQ3syEh87pCDRqEb8fIXDDabgxkOHkPdQmJhRkWkIP4fKdOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1727218779; x=1727305179; bh=d8fUlRHE2iZfy80BDgU0TCA1aV71 a21YfiFtM5egfSU=; b=naAS52CC4mk6nmZPC08I6+3XtolR88HMhgLx24YxES/7 rVwRp/rh7wTozU6t7CNSzk7J7n9GnZAxLnTFf2Sc5RJzgXHYelclqepTLZHdgPyN QQjKoRXyxtx8afvdUdnxtXW9cu7VFFrBEjo1dp/Nh2if4qh+OU4n5ERypTUMRxox pqyLrayTFkgpT1mqrIpvKcQnFmy8/k884Iu7iD+4srs08/Lp/MvQV64M0dGNYrF2 3dOJ5dXlfrQGQUeFqHeolbwgcGFdnVQY24VL2fuqoueGV481yc7UPiyKCmgGSZV1 mbmm7i6oJrEv1qfCYechgy//sESy0s5rB7BMgyxMEw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddtgedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvden ucfhrhhomhepvfihtghhohcutehnuggvrhhsvghnuceothihtghhohesthihtghhohdrph hiiiiirgeqnecuggftrfgrthhtvghrnhepueettdetgfejfeffheffffekjeeuveeifedu leegjedutdefffetkeelhfelleetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepthihtghhohesthihtghhohdrphhiiiiirgdpnhgspghrtghp thhtohepudegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehkvggvsheskhgvrh hnvghlrdhorhhgpdhrtghpthhtohepvggsihgvuggvrhhmseigmhhishhsihhonhdrtgho mhdprhgtphhtthhopehvihhrohesiigvnhhivhdrlhhinhhugidrohhrghdruhhkpdhrtg hpthhtohepsghrrghunhgvrheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepjhgrtghk sehsuhhsvgdrtgiipdhrtghpthhtohepjhhlrgihthhonheskhgvrhhnvghlrdhorhhgpd hrtghpthhtoheptghhuhgtkhdrlhgvvhgvrhesohhrrggtlhgvrdgtohhmpdhrtghpthht oheprghlvgigrdgrrhhinhhgsehgmhgrihhlrdgtohhmpdhrtghpthhtoheplhhinhhugi dqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Sep 2024 18:59:35 -0400 (EDT) Date: Tue, 24 Sep 2024 16:59:33 -0600 From: Tycho Andersen To: Kees Cook Cc: "Eric W. Biederman" , Alexander Viro , Christian Brauner , Jan Kara , Jeff Layton , Chuck Lever , Alexander Aring , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Tycho Andersen , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Aleksa Sarai Subject: Re: [RFC] exec: add a flag for "reasonable" execveat() comm Message-ID: References: <20240924141001.116584-1-tycho@tycho.pizza> <87msjx9ciw.fsf@email.froward.int.ebiederm.org> <8D545969-2EFA-419A-B988-74AD0C26020C@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D545969-2EFA-419A-B988-74AD0C26020C@kernel.org> X-Stat-Signature: 9ryay5ta9r13hkta8abxy6iit4jpdyhp X-Rspamd-Queue-Id: 597CC40006 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727218780-896704 X-HE-Meta: U2FsdGVkX18r9TS8y8nezfFbT5kxn9Q4Rmn/JFJZUV8TDzD5Uk6Jy3065mbzCbAUwROibFM5d+WexYJuvyxlQOO6uKDDhoy+rijYMiOx0J44PWtGo13idGDJqH7cc06m31LhEnrWVoH66Hcky84UyDd3jvH/LjWBSQgHhVmkupcMmA/vD4NkwdJEmGz+uz9HZZ6Qf/8cjJCyn8RjdfRy3yGoooV2YCC99M/TuEflaASVEYagfrMwm4iXAnZepNhLRykuAJck7pt1KdX10PmAOkWW+Pvpl76Z++ic57qafUaZ9kxAASgHqS30DGeFnPu+kazhZW7TIBEvXOll0Hdmwmoc9JeSD1v/m4neGOx6sWZq3Q6E3csiCKItnplv5VoROIhfNaTdEXQIef0Rzp9d5H5BYmfZZG73m9NkyvoaX/2S3s8+2T78zgDjiMunhiw9b6ZV4Vpx2YL29C5ZB5kANQ0rQcPmyfde1Fhkt5UEcLpCI0WE8Zbx0apbMOGMSO1hVZ0jV4PLBJA5iflqQk9kIAdSeMOzJ+h9mbqmlRlx5BtqtSBAbHhPxmT2bNeYovCuuJ48ToAxOBCZAkcx1jMRwslFeZyP8IGR7ARnNT23djznJ5MnL5BmLsd11Rfxb0sSwI11ptrvNLmyim1LZRO/nBEejY/RhD4PssxtuJQR/MFw28kON7+tcmIHj/+bbwqu3riEFzanR8BB77QhtJ6uPfZJ/aX0jmy1kYmSMyKtmMJjOEdryqq3y0kF+JGqqsYCBkj7oQMDluGmAmoBiZV+xmVf76KzFu+KSepHMJeYpEw8zliqnnY02E0pMkf6tGOOtDkFDozVhF2HD+njiWWrtnLtMoyJrIgBXkM8ZyEXwbXV8/72TNUxOYFR046JOB6//A+w9e77bBCxvmNd5en9MPZfOBKY36Rn5zwwlg43tbbJRl15iC3BcjEvc1sVMbYEia7nezQYMDKXxE7pGCn mKCxMlmn PINSDdoRfm43THXzPOAQwB2CsK6QDtL9yaQi7eCVKZY/27BrBVn7Yicn2hXCkJ52dJLgQj5WSBwpv9qMu4hHuRmiQf4jsC2bebE/nnShW8cC3+OX1t7j65h7DyhZTtXwjC+RBVtzVDIMGRp1MzPnuogW1RY6D4N6r93rTn7HXHrKz2IXvyiQebqRPvyQ4Jwk43a+kO3kjCPgozfNkvydyrRydPX/okFtNRuE2UdeCFl7WpT0EAm1lcBzjHJeopn/alt417h4PyVxn0q5Tbc+pmGuzQ+6sk8fEzBYgDjda1Resm39LHeinQeM88xhDstDc2glzEpXrkUS7xDYI6MDasZa1fgItqSE8V4cRDjgR/1O0SVxuuegoNfGMxnG5UYW6b+jYYOYfm3Mm9fJAtSNARHhgyp2a3U3FhTqKaq/lyckXQp4Zu27k1khvKImpsJFVxX2iDTlthU69jpQ= 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, Sep 24, 2024 at 02:37:13PM -0700, Kees Cook wrote: > > > On September 24, 2024 10:39:35 AM PDT, "Eric W. Biederman" wrote: > >Tycho Andersen writes: > > > >> 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. > > And just to double check: systemd's use would be entirely cosmetic, yes? I think it's not really systemd, but their concern for admins looking at `ps` and being confused by "4 is using lots of CPU". IIUC systemd won't actually use the value at all. Zbigniew can confirm though. > >> > >> This patch adds an AT_ flag to fix up /proc/pid/comm to instead be the > >> contents of argv[0], instead of the fdno. > > > >The kernel allows prctl(PR_SET_NAME, ...) without any permission > >checks so adding an AT_ flat to use argv[0] instead of the execed > >filename seems reasonable. > > > >Maybe the flag should be called AT_NAME_ARGV0. > > If we add an AT flag I like this name. +1 > > > > > >That said I am trying to remember why we picked /dev/fd/N, as the > >filename. > > > >My memory is that we couldn't think of anything more reasonable to use. > >Looking at commit 51f39a1f0cea ("syscalls: implement execveat() system > >call") unfortunately doesn't clarify anything for me, except that > >/dev/fd/N was a reasonable choice. > > > >I am thinking the code could reasonably try: > > get_fs_root_rcu(current->fs, &root); > > path = __d_path(file->f_path, root, buf, buflen); > > > >To see if a path to the file from the current root directory can be > >found. For files that are not reachable from the current root the code > >still need to fallback to /dev/fd/N. > > > >Do you think you can investigate that and see if that would generate > >a reasonable task->comm? > > > >If for no other reason than because it would generate a usable result > >for #! scripts, without /proc mounted. > > > > > >It looks like a reasonable case can be made that while /dev/fd/N is > >a good path for interpreters, it is never a good choice for comm, > >so perhaps we could always use argv[0] if the fdpath is of the > >form /dev/fd/N. > > I haven't had a chance to go look closely yet, but this was the same thought I had when I first read this RFC. Nobody really wants a dev path in comm. Can we do this unconditionally? (And if argv0 is empty, use dev path...) We can, I was just worried about the behavior change. But it seems we are all in violent agreement that the current behavior isn't very good, so maybe it's fine to change. > >All of that said I am not a fan of the implementation below as it has > >the side effect of replacing /dev/fd/N with a filename that is not > >usable by #! interpreters. So I suggest an implementation that affects > >task->comm and not brpm->filename. > > Also agreed. There is already enough fiddly usage of the bprm filename/interpreter/fdpath members -- the argv0 stuff should be distinct. Perhaps store a pointer to argv0 during arg copy? I need to go look but I'm still AFK/OoO... Yeah, on second thought we could do something like: diff --git a/fs/exec.c b/fs/exec.c index 36434feddb7b..a45ea270cc43 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1416,7 +1416,10 @@ int begin_new_exec(struct linux_binprm * bprm) set_dumpable(current->mm, SUID_DUMP_USER); perf_event_exec(); - __set_task_comm(me, kbasename(bprm->filename), true); + if (needs_comm_fixup) + __set_task_comm(me, argv0, true); + else + __set_task_comm(me, kbasename(bprm->filename), true); /* An exec changes our domain. We are no longer part of the thread group */ and then we don't need to mess with bprm at all. Seems much cleaner. I will see about the get_fs_root_rcu(current->fs, &root); path = __d_path(file->f_path, root, buf, buflen); that Eric suggested and how that works with the above. Tycho