linux-kernel - Re: [PATCH v3 1/2] exec: fix up /proc/pid/comm in the execveat(AT_EMPTY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Zv1UJmR1UZUG2P/t@tycho.pizza>
Date: Wed, 2 Oct 2024 08:09:42 -0600
From: Tycho Andersen <tycho@...ho.pizza>
To: Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>
Cc: Aleksa Sarai <cyphar@...har.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Eric Biederman <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	Tycho Andersen <tandersen@...flix.com>
Subject: Re: [PATCH v3 1/2] exec: fix up /proc/pid/comm in the
 execveat(AT_EMPTY_PATH) case

On Wed, Oct 02, 2024 at 01:45:15PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Oct 01, 2024 at 08:42:56PM +0200, Aleksa Sarai wrote:
> > On 2024-10-01, Tycho Andersen <tycho@...ho.pizza> wrote:
> > > From: Tycho Andersen <tandersen@...flix.com>
> > > 
> > > 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
> 
...

> Unfortunately, I don't think that the approach with
> f_path.dentry->d_name.name can be used :(

hmm. Somehow earlier I had managed to convince myself that this gives
the right answer for symlinks too (instead of the original
kbasename(__d_path(file->f_path, root, buf, buflen)), but now upon
retesting it doesn't. So I agree, seems like the argv[0] hack is
needed unfortunately.

Tycho