Re: [GIT PULL] execve updates for v6.13-rc1

["Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>]

On Wed, Nov 20, 2024 at 06:23:55PM -0800, Linus Torvalds wrote:
> On Wed, 20 Nov 2024 at 16:55, Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> > __set_task_comm cannot be called with bprm->file->f_dentry
> > unconditionally.
> 
> No, no. Only for the "no path" case.
> 
> > The reason bprm->file->f_dentry.dentry was abandoned were concerns
> > about breaking userspace.
> 
> There's no way it can break user space considering that right now
> comm[] ends up being just garbage.

It'll "break userspace" in the sense the the resulting program name
visible in /proc/self/{comm,stat,status} would be different than the
expected value. Currently userspace is not using fexecve because this
string is "just garbage". We'd very much like to start using fexecve,
but we cannot do this (in the general case) if that'll result in a
changed program name. If we change the value from the current
(garbage) value to something that doesn't provide identical behaviour
between execve and fexecve, fexecve will unused.

As Eric wrote, there are various programs which are symlinked.
/etc/alternatives is one group, but we also have "multicall binaries"
which present different behaviour depending on the name.
Some of those use argv[0], but other may use comm.
We really need the name that the user called the program as,
not the name after symlink chasing.

Even if we end up copying a string from userspace unnecessarilly,
does this matter? execve is a heavyweight operation and copying a
a dozen bytes extra hardly matters.

Zbyszek