It is sometimes desirable to launch stap-server processes on a machine with multiple sets of kernel-debuginfo/devel installed (as in a master compilation server), or for cross-arch purposes. For this to work, each stap-server needs to accept some arguments at startup time (at least -a, -r, -B, for the nonce). OTOH, unprivileged mode support specifically disabled some of these flags within stap. Yet we want that too. So it seems like a possible solution is to clarify what stap options may be passed through which layer. It seems as though stap-server should pass some server-admin-specified flags (might as well come from stap-start-server), and block these same ones from clients (as they arrive from stap-client or whatever in the request-containing zip file). It'd have to safely collate the two lists of options, and pass them to plain stap. Since stap-server would now perform stap argument sanitization, it becomes probably the best place to do module-signing. That means stap wouldn't do it (even in the --unprivileged case), just include some more constraints during the translation process.
With this proposed change the usage module officially changes from "in order to have their modules loaded, unprivileged users should compile their modules using a systemtap server" to "in order to have their modules loaded, unprivileged users *must* compile their modules using a systemtap server".
(In reply to comment #1) > With this proposed change the usage module officially changes from "in order to > have their modules loaded, unprivileged users SHOULD compile their modules using > a systemtap server" [... but now MUST ...] What other way is there that we are about to sacrifice?
done