Why silently ignore the `LINUXCNC_FORCE_REALTIME` environment variable if some other `rtapi_app` binary doesn't have setuid?

[wucke13]

I'm currently packaging LinuxCNC on NixOS, and I find some design choices rather appalling.

LinuxCNC tries very hard to detect whether it is real-time capable. And this logic is flawed in multiple ways, at least from my point of view.

1. rt_api explicitly checks for setuid as root, as opposed to, just the needed capabilities. I guess for uspace with PREEMPT_RT kernel cap_net_admin,cap_sys_nice,cap_sys_resource+p would suffice, but oh well.
2. It does not check this on argv[0] (the actual file executable), but on on EMC2_BIN_DIR "/rtapi_app", regardless of whether that is the file which was called.
3. It does check this, before considering the LINUXCNC_FORCE_REALTIME, silently rendering that mechanism useless.

Now, on NixOS this causes a problem, because all applications reside in /nix/store and never have the setuid bit (or any file based capabilities) set. For things like sudo or rtapi_app, we usually create a wrapper with setuid set under /run/wrappers/bin/, than dispatching (I'm not sure how, I believe via exec) to the actual executable in /nix/store.

Regardless of my niche use-case on running LinuxCNC on NixOS, in general, I think at least the LINUXCNC_FORCE_REALTIME should be honored in all cases.

linuxcnc/src/rtapi/uspace_common.h

Lines 412 to 416 in 568354c

	struct stat st;
	if ((stat(EMC2_BIN_DIR "/rtapi_app", &st) < 0)
	|| st.st_uid != 0 || !(st.st_mode & S_ISUID))
	return 0;
	return detect_env_override() || detect_preempt_rt() || detect_rtai() || detect_xenomai() || detect_xenomai_evl();

[andypugh]

There was some work on removing the reliance on setuid, bit it somewhat stalled.
#918