The provided way to identify applications is unreliable

[Ongy]

Unless I am worse at C than I thought, the implemented way to determine the application binary path is to read the /proc/[pid]/exe symlink.

This is sadly not a reliable way. The symlink is always given in the applications mount namespace, not the compositors mount namespace. With unprivileged user namespaces (which afaik most distributions have available for lxc/docker/etc.) any user application can abuse this to gain any path.

I think this can be (paritally) mitigated by checking /proc/[pid]/ns/nmt and compare it with /proc/self/ns/mnt.

As secondary problem, applications that use interpreters (such as python) will show up as the interpreter. And sadly /proc/[pid]/cmdline is not reliable either to determine which file is interpreted.

[Sidnioulz]

HI,

This was written before user namespaces were "stable", so you're right to point out a now valid limitation. Your approach is similar to what I've done in a similar project and I believe you're right.

You're totally right about interpreted apps showing up as the interpreter. This is partly mitigable, but not always. However, the issue can be eliminated for DE-launched apps if the DE provides a method for libwsm to identify running applications, with a "Desktop" concept of running application that currently lacks standardisation on Linux.

[emersion]

Actually, there is one more potential attack scenario. It exploits the fact that PIDs can be re-used. More details here: https://github.com/swaywm/sway/pull/3088#issuecomment-456078987