Comment 4 for bug 1901572

I agree that the LD_LIBRARY_PATH should be cleaned up.

In terms of the snap application, it is always going to be confined via the sandbox and will be as open or closed as this allows (eg, the x11 plug necessarily gives a lot of access due to the design of X, which is why things like xdotool allows you to do so much). Therefore, from the POV of the *snap*, this is not a security vulnerability (it doesn't need the shared lib from the host, it could just do that (ie, use xdotool)).

In terms of the *user*, the user doesn't need to hop through a snap application to break out of confinement, the user is already unconfined. In other words, the user doesn't need to put a shared lib on the system, then run a snap to have access to /etc/issue or run xdotool. The user can just perform those actions directly.

Where things get more interesting though is that a malicious snap with the home interface connected could target other snaps by writing out a crafted library then wait for another snap to be executed from this directory. That crafted library could exfiltrate data or run other commands within the context of the other snap. As such, I think this does constitute a security vulnerability.

IME the bug is in snapcraft, but we should look at snapd to explore if we should harden its 'environment' handling to remove the current directory from various env vars.