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 09E93CF6491 for ; Sat, 28 Sep 2024 21:56:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 633596B0155; Sat, 28 Sep 2024 17:56:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BEA86B015B; Sat, 28 Sep 2024 17:56:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4366E6B0157; Sat, 28 Sep 2024 17:56:07 -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 215C96B0153 for ; Sat, 28 Sep 2024 17:56:07 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8E87180AD0 for ; Sat, 28 Sep 2024 21:56:06 +0000 (UTC) X-FDA: 82615505532.25.F0C3CA1 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf08.hostedemail.com (Postfix) with ESMTP id E373816000D for ; Sat, 28 Sep 2024 21:56:03 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Teb2HkVS; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727560545; a=rsa-sha256; cv=none; b=UFsqahRQslbdk+661pYU+RDoX3MHYhi1NODaIqAtINXY3mKDocK+Fm2YDZt0uG8YHlX56z FaIOrp2OzXV92usXkaXtyX+/i57vijY632ITsLLav/DMO/fM3OGZmAla8KjkWwXd1uExWR dBg+Shvy8p2ndYdBeLJwooUpEeFTRWI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Teb2HkVS; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of kees@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727560545; 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:dkim-signature; bh=o08iF2Dp98U9KXAH2MFvq4OaCXDYZ7e68evos/sIudU=; b=tC8NO2pKw6LVhzHw2WGi1a6rETGjA0hKg5yVPCfY+YSrNMS9PlpAU9INIvsgAfltpYyeBg AUP7ClVl1zYNBKnC7U62kKSXuYs489KwP3wojLiUpncgkIOfu5EXpTDujSKlrBATPY+vOu qEPXKQTZRXGPAy2jmiaEVlpno5c8JaU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 0E178A40108; Sat, 28 Sep 2024 21:55:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1605C4CEC3; Sat, 28 Sep 2024 21:56:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1727560563; bh=Bls5swmpeMzUWj2RlsQGBW8bINZMXO0c0CeG2/n6aR0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Teb2HkVSXlHPGKaQcYTedlkoVOlbSwhrrHJD0daluNnTdurb5ZsbWx4N/mlLU3GVJ uTJuNrdK0n2GyH6iTeTPQRWzyCGKBkaFYMN+ED6ybnoII/TOZg7zbMBk7IfPu2+YLE akqKzVjZSHmpndorYJ3AcDK0ROyPcMDoQSfp8+K3M3gSHrxWKWIgkLcCO5So2Gafk7 EReey6Ip1vTAFTo+Xj/JKL5Gyhrgp9SfWyfRdnXA0H0umdKOJcEu3gCiPUv9N2SosM 8B0QXa2iZV93R3OQUvaCk4dmersJxQSJp/yPDdyYo58dEbHX2AEbj8xHsyCT+ML2Ak Narrp1bIfYvoQ== Date: Sat, 28 Sep 2024 14:56:02 -0700 From: Kees Cook To: "Eric W. Biederman" Cc: Tycho Andersen , Alexander Viro , Christian Brauner , Jan Kara , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Tycho Andersen , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , Aleksa Sarai Subject: Re: [PATCH v2 1/2] exec: add a flag for "reasonable" execveat() comm Message-ID: <202409281453.B9B9999D@keescook> References: <20240927151746.391931-1-tycho@tycho.pizza> <87ikuhw155.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ikuhw155.fsf@email.froward.int.ebiederm.org> X-Rspam-User: X-Stat-Signature: tupsbjwr1xwhwzi1f6ue9h1szs7qdnmk X-Rspamd-Queue-Id: E373816000D X-Rspamd-Server: rspam02 X-HE-Tag: 1727560563-349783 X-HE-Meta: U2FsdGVkX19W6vGAmAacMI3B/GGhIdnPnj5BIZQLTlMXv9Li5RYUcqSJtEsRuGm3RNcsvebn1WMdgXPZZJcI6fKrF8uDft4Qi65SrRMQ3FxwdQf12MRMSJ/1uoWzq0SooLzpTlKbCM2MJgpPYVczBhM+mbOBM/uvd9oyRTNjoH4LahHSrfQyc+dPheBcR4/0TQ189+n/27tjhuQt0ZUEUgxJFqI80PwSGbiOlSpdulxew7solf5Syxwgj7XSNUfxmVmq+8eIwNErVzIz9kHJ83ZILT75OID1/8tZ+1qxGITEUPsMLeRNNfMOwbEKSRKygwWScbALsaYUU7Pxsrse3qB94SKA13ZynM+50/h04/ppQcAIl8guWGQuQZHlvhE1zOxR9YFHubMnvSzsPf1aS5ik0VAkYtdSIiJNotXNCGZwqRdAFJ/WX6OW2r/zzOOBWJbKsCxa0vzPrL8EpAi2aOWpcGWOi1iq622pGWP4JtSvdJ8SxyXGpWZyRj5hmky9/22q1XEbtDiTmIos/WFU/7lhIGmTQqL7aSlYA63AdeGu4MH9p5pyyCRHqGVJcmtxXw0zfjsdj/7HOS5TON6CBFwaqSrXgWNfh1sOPE0JLtKEkwGLb5ytrBe+D9h5Y8cfEzKUdIH+eABLhT/R6Uo9HPy4vUmhlN9LG8jIQcfK6KKWgL3Yv+Ie8p42x7d2NezGHrHDhB1vHU1MoEYB8b7yBgIfWUFc4nCcSoia4nBMjRmS9Syl6W/VNdrhE/BXYfi6zrY6+1/FkeQ3TCiFCP8F0M0ak74RQHwesL7dwbY+rybIiECiFJTCRGPGYOiwr+8TzdAMxu4rnXH7mvZjMuTTkQOot5t086G4IezxuRCGcpEWbI++uWV4lHWk6wMiYk9gy4pt8ynWqZOlsr3PtMWW22UsDJta0PcerTcOrRAwjaAgpkfpnv1SG/xzJYyl7A/ODrGtc/5mds+rb2vMAen Jmlw0LJB cqlcuNER5C1cH2oa9KgsC2DNuZaI1KMhKddiLVElr6Y+NIiX3BuBalz+TQw/z3q0E6yLJVHa2vfoogNGv5oWsojSNiWFwIu9BRIGjD1YzZGYqsySLa4dHsKmQ8bUPARFWWPgl7/NPqC7razSTq8UYbzHr7rKHWX8CdYLHGACXpr5EsNXMWHRqd24bIMUxnLUuFcOPIY3voVkC0O1l9zS75JTM05iXj+5TEcshyhFwlkv+Ls9z+rbCiMKoMeh2BxZg9bnEakRQmve5205PfiakcFLGgsEtZzJoFRqZ+xfIMaI1GCIyEJzXKvlPCAJKftY/S5fOSFXu6ecWR247f9u2BItgDYrJwKGaLW6FAtNpn5i4QSw5v9JDdxT1Y8EM9AFpJY8x 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 Fri, Sep 27, 2024 at 10:45:58AM -0500, 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. > > > > 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. > > Perhaps change the subject to match the code. > > > Signed-off-by: Tycho Andersen > > Suggested-by: Zbigniew Jędrzejewski-Szmek > > CC: Aleksa Sarai > > Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec > > --- > > v2: * drop the flag, everyone :) > > * change the rendered value to f_path.dentry->d_name.name instead of > > argv[0], Eric > > --- > > fs/exec.c | 13 ++++++++++++- > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > diff --git a/fs/exec.c b/fs/exec.c > > index dad402d55681..9520359a8dcc 100644 > > --- a/fs/exec.c > > +++ b/fs/exec.c > > @@ -1416,7 +1416,18 @@ 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 fdpath was set, execveat() made up a path that will > > + * probably not be useful to admins running ps or similar. > > + * Let's fix it up to be something reasonable. > > + */ > > + if (bprm->fdpath) { > > + BUILD_BUG_ON(TASK_COMM_LEN > DNAME_INLINE_LEN); > > + __set_task_comm(me, bprm->file->f_path.dentry->d_name.name, true); > > We can just do this regardless of bprm->fdpath. > > It will be a change of behavior on when executing symlinks and possibly > mount points but I don't think we care. If we do then we can add make > it conditional with "if (bprm->fdpath)" > > At the very least using the above version unconditionally ought to flush > out any bugs. I'm not super comfortable doing this regardless of bprm->fdpath; that seems like too many cases getting changed. Can we just leave it as depending on bprm->fdpath? Also, is d_name.name always going to be set? e.g. what about memfd, etc? -- Kees Cook