Currently, the oz client may be invoked by any user. This can lead to some nasty issues like X-based hangs if the user attempts to launch an oz sandboxed-application as root.
It seems that minimally, oz should reject invocations by (e)uid 0. But examining this issue at a deeper level might also reveal some deeper, more generic bug.
Other than rejecting oz client usage by root (perhaps the "list", "profiles" and "logs" sub-commands should be exempted), should any other user accounts be blacklisted? Or conversely, should the oz client interface only be usable the standard default "user" SGOS account?
shw700
commented
7 years ago
Currently, the oz client may be invoked by any user. This can lead to some nasty issues like X-based hangs if the user attempts to launch an oz sandboxed-application as root. It seems that minimally, oz should reject invocations by (e)uid 0. But examining this issue at a deeper level might also reveal some deeper, more generic bug.
Other than rejecting oz client usage by root (perhaps the "list", "profiles" and "logs" sub-commands should be exempted), should any other user accounts be blacklisted? Or conversely, should the oz client interface only be usable the standard default "user" SGOS account?