Comment 1 for bug 1682411

This isn't on arbitrary machines, but it is true on machines that were deployed with Juju.

"juju-run" runs inside of a hook context, which is inherently defined as 'run as root'.

We could potentially filter out access to juju-run via a group. The 'ubuntu' user would obviously be in that group, and charms could potentially add other users if they wanted to.

The actual goal is to allow running applications to report back information (for example juju-run status-set "blocked" "something is wrong").

We could try to limit the context of 'juju-run' to a non-root context, but then it inherently doesn't have full charm context. That would also affect people using:
 juju run --all myscript

since that would change the privileges that you have for myscript.

Its a bit hard to say "apps have access to juju-run if they want to run something in a charm context" but then say "but you don't have root access, which is what charm context is".

Needs some thought, to sort out what is really useful for an application to have access to (setting live status would be very useful), vs what vulnerabilities we raise. (apt install apache defaults to not letting the apache user get access to root.)