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 1A5C2CCF9F7 for ; Wed, 25 Sep 2024 21:20:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B2556B00A4; Wed, 25 Sep 2024 17:20:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63AD56B00A5; Wed, 25 Sep 2024 17:20:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48D5B6B00AC; Wed, 25 Sep 2024 17:20:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2576A6B00A4 for ; Wed, 25 Sep 2024 17:20:30 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9D2F1141018 for ; Wed, 25 Sep 2024 21:20:29 +0000 (UTC) X-FDA: 82604529378.26.D6F5C40 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) by imf03.hostedemail.com (Postfix) with ESMTP id 605B22000C for ; Wed, 25 Sep 2024 21:20:27 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=tycho.pizza header.s=fm1 header.b=ftyCfFEq; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=fPJI5GWv; spf=pass (imf03.hostedemail.com: domain of tycho@tycho.pizza designates 103.168.172.151 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=1727299108; 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=knJ0ZhwDbbGACsQWxBY9OilKWDC1g00F6Yfm+LjMVHU=; b=xxQOEcUZQAa3e6UN/7p9PCMKDw1OouS7AEdiM1Koiv0Vdi2z7E/+sAHpEj+QZ+uhfwJPJ7 BVbxfGoHHH56Xr78AcMOrFASLjYFKQKNb1mgHawPexukWOrBwW0m/JsTNY9+zw9PyQlr+i kcv/dLZfqxsv9zfiT860sYATn+o3oZY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727299108; a=rsa-sha256; cv=none; b=cd1kMepO62Z1sJXrxYf2rEbGKnsxXqvpDHxk1/Tj9WkULDI8pOwRaMigpbXz7Byn9KePXC 6RsnfvxxwCGe+yjSVGKjtZHoVXXlTY2FhWwjL7kSysG5AET+Spe88fPN0W698tcY4FN6ZT neQJFNZPSaC6yGqluYxSTWBFlB2G5BY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=tycho.pizza header.s=fm1 header.b=ftyCfFEq; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=fPJI5GWv; spf=pass (imf03.hostedemail.com: domain of tycho@tycho.pizza designates 103.168.172.151 as permitted sender) smtp.mailfrom=tycho@tycho.pizza; dmarc=none Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfout.phl.internal (Postfix) with ESMTP id 8C4651380249; Wed, 25 Sep 2024 17:20:26 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-12.internal (MEProxy); Wed, 25 Sep 2024 17:20:26 -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=1727299226; x=1727385626; bh=knJ0ZhwDbb GACsQWxBY9OilKWDC1g00F6Yfm+LjMVHU=; b=ftyCfFEqY5zqgYKhpaAiNeDaJo RUCpm5n+muNT2xZ2iFq656bTOw8teKQD1n6QozbSVRKfa59d1Y0ItdlQVh9LE+E1 QKexRy3XHmPwaiewpzKT6bfllow4OMs9lx8Yz/azGwxZnXCljBwPE+YK4lAZZsTy Ca//PA585G/92oHitDnFjzHstW1VXtYw4ToHmQgqq66fQld+mapS3fIlEMK0hc3L N/3PZL1904aSMh1SvDOlxFUj4RyfGPoKJlew02J3ta2+AtPbQBRa6KoAow99+KcL OjkDvcqxkSG9nKm3NHombOn35+a5AsTizZL6LMQgEJEQaIZYQ8OdxhFsKjkw== 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=1727299226; x=1727385626; bh=knJ0ZhwDbbGACsQWxBY9OilKWDC1 g00F6Yfm+LjMVHU=; b=fPJI5GWv1/hRU1mjDOJ3a0WFF256VuWg6vxPo6FDp/5w OuQZjWq1pBd2AynPOFyxhd08iT1UMVm9ICNI9lYgXyCpHpO+p7OIYwiJS8DOeIXJ bAaw+pwaLDTZgCSZafx4nzitsq22En8VyBJh3osUsgh3FgJtxgVB3BAWsrrnGA+x II710q/vNEYBX/5AzInFLOkfBjOvk4AfC9s4qjv8RECkzMxHleLT3Q15jDa1js46 elnD14Gkn/Mngl18YqUXVAlG8Bp50WUWDV730xzftmR7aZal7I+aAz5XW4jJQuTi XOHwSKnAapc8XIkmwncorzYY3ewyrcw6zoxRPBEeEA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddthedgudehlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddv necuhfhrohhmpefvhigthhhoucetnhguvghrshgvnhcuoehthigthhhosehthigthhhord hpihiiiigrqeenucggtffrrghtthgvrhhnpeeutedttefgjeefffehffffkeejueevieef udelgeejuddtfeffteeklefhleelteenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehthigthhhosehthigthhhordhpihiiiigrpdhnsggprhgt phhtthhopedugedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheptgihphhhrghrse gthihphhgrrhdrtghomhdprhgtphhtthhopegvsghivgguvghrmhesgihmihhsshhiohhn rdgtohhmpdhrtghpthhtohepvhhirhhoseiivghnihhvrdhlihhnuhigrdhorhhgrdhukh dprhgtphhtthhopegsrhgruhhnvghrsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehj rggtkhesshhushgvrdgtiidprhgtphhtthhopehkvggvsheskhgvrhhnvghlrdhorhhgpd hrtghpthhtohepjhhlrgihthhonheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheptghh uhgtkhdrlhgvvhgvrhesohhrrggtlhgvrdgtohhmpdhrtghpthhtoheprghlvgigrdgrrh hinhhgsehgmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i21f147d5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 25 Sep 2024 17:20:22 -0400 (EDT) Date: Wed, 25 Sep 2024 15:20:19 -0600 From: Tycho Andersen To: Aleksa Sarai Cc: "Eric W. Biederman" , Alexander Viro , Christian Brauner , Jan Kara , Kees Cook , 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?= 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> <20240925.152228-private.conflict.frozen.trios-TdUGhuI5Sb4v@cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240925.152228-private.conflict.frozen.trios-TdUGhuI5Sb4v@cyphar.com> X-Rspamd-Queue-Id: 605B22000C X-Stat-Signature: oq1oguhaibxgr9wkuh6wfqj9kz8wgixs X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727299227-756135 X-HE-Meta: U2FsdGVkX1+7QQs3ywTkzUBPfczbDkiBp4uGtqXdbJ3mI+JdVQYXJ+xVaWSVW1KefY7JkiXOEBt11pO2TrUqByjXch85LUYDtMbABQzQGciQJVP0EU7BBg+jz7dexD5yMkdyEiew+trxSeenukng91diXujX3eaOCoHATlk4dby9zbm0sFbTsPfJrkLpxm3nGtWQrkd5S3rl+K0cE7bhQrzR9hqBtMs4pMV5gpniBvZg7LO3V00SSKou78hwrjEeLVcWru2pRTRLMcIn3JhSVEl01ueV2qdgUc0506IExnizMe97Nh8i95gR3OuHwUzuvmsksyLXM7WI1Fq8NjMxiZbn73OGYJsbP1eCjcrpVAg390j6Eh0zn+0TgnZo5ZUWUT1BpTwaw7Mxb4PPUNOpKmP6192mVK3vlixo6gjaytM0hbRxwWGuoSrPBqeUU0IXR1biU4Q5PN0Zx3r7Un5vdvtIldUEytXIgZHScolOnN/s8MGg/91eOZ2b+pxrjLSaY2VQkf84cvPSoAXi7lzhDBTPkd/p+ZQV85zabRCyO8iKQMQFwM6xUmCblMs25MShwN335qLMcHOe17zPFxwjsqxda6Y8PaTeLLaFGh4XGV561pLW61dkmgbbOcRnFIZ4ibf2Z4B9zM84fdhq/yOqjXd7CzkZ4HSDqp9K6qBxxDUwyA5O07oqhrgrE2E34iP+907ZraXEk4g1diH606XWkKnhVxttJMgO62lxiwVpVU9qpa01ZK0Tvi0xLFk3tLl1PIMzvEYHgJjeDYxu+aHurxLm5J4XfftD5/982VoxCME6nVNR3zPiyjyGnasV8VaWFVd4p6Q+cFgfU1qfseIPsXr3qdd3ld3PytsrT4faS9e+haAXDEZZV7z9MhnVYuOwJHnr1n3yrs4P5FjbEfMzdiR5p7qakgB3C3YslNjGl43wA99AS6XZ435KMmalzAFgIZcKfYHKE73TelL75+m Jii+V0cy liwAFZppOQCEJ7RvFf7TnEqk+2R3aCY+j4gDED8sRw0i6ESne99cCinTetfT0QNtJPeqj27DgPky4o36uLFTl8fbJqhhHu4ntlHHoOfKfhmn28vs2N/k4VtHeDmE8qTNtsDrY1ezzs3ziTK+9qeIbWobYyhH3byh689dAzL1tiCXTBhC5nomv4iHvZRWsctE4TVG/4wBWb4U9Zz1lyanBOS3xx2M7r19oD2p6UCKWBFr69gdGCBi7yGFYTpetQ10fOITQDhzAhtZi1xQuMzhwAw/N6MEZWewhODdOrUQMaosVSINGysZGLamKmKjvZJNIr6c8lteNHrKA/ZLi4/OgdzGF6PG4pRt1fCSzrgSvYFmezAb1qDiWK8E5Fc7cQidtG9rl5+Lcv1ZOQSZf5d+JtFcPaCIicq9FIT36j4mDOv3Ga755aztZZTS3usG7vnPR432Zj+agsQPUMgQ= 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 Wed, Sep 25, 2024 at 05:50:10PM +0200, Aleksa Sarai wrote: > On 2024-09-24, 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. > > > > > > 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. > > > > > > 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? > > The problem mentioned during the discussion after the talk was that > busybox symlinks everything to the same program, so using d_path will > give somewhat confusing results and so separate behaviour is still > needed (though to be fair, the current results are also confusing). I also remember that busybox used to do symlinks, but I just looked the latest version on the docker hub (perhaps not representative...) and it's all hard links, which works fine with the __d_path() trick. > > 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. > > > > 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. > > I think only affecting task->comm would be ideal. Yep, I did this for the test above, and it worked fine: if (bprm->fdpath) { /* * 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. */ struct path root; char *path, buf[1024]; get_fs_root(current->fs, &root); path = __d_path(&bprm->file->f_path, &root, buf, sizeof(buf)); __set_task_comm(me, kbasename(path), true); } else { __set_task_comm(me, kbasename(bprm->filename), true); } obviously we don't want a stack allocated buffer, but triggering on ->fdpath != NULL seems like the right thing, so we won't need a flag either. The question is: argv[0] or __d_path()? Tycho