| |||||||||||||
RealtimeKit and the audio problemRealtimeKit and the audio problemPosted Jul 2, 2009 9:52 UTC (Thu) by mlankhorst (subscriber, #52260)Parent article: RealtimeKit and the audio problem
What's wrong with just setting the app setuid root, calling rlimit cap and then try to set that no-inherit-scheduler flag before dropping to user privileges?
(Log in to post comments)
RealtimeKit and the audio problem Posted Jul 3, 2009 4:00 UTC (Fri) by nedko (subscriber, #59419) [Link]
First, with stuid root process will be able to do everything. With realtime capability it can only do DoS. With root access it can delete every single file on your filesystem.
Second, JACK is not designed to be run as root user.
RealtimeKit and the audio problem Posted Jul 3, 2009 16:52 UTC (Fri) by quotemstr (subscriber, #45331) [Link] Did you read the comment you're replying to, or did you not quite grasp it?The OP said to use the setuid mechanism, which means that the process starts as root, grants itself realtime privileges, then irrecoverably becomes a normal process in every respect except that it can elevate its scheduling priority. Your concerns simply don't apply. In fact, you could write a small wrapper to grant this realtime capability before launching the real program so that the bulk of the code doesn't have to mess with setuid-stuff at all. Err, wait -- it's been written, and it's called set_rlimits. (Granted, set_rlimits should use PAM, but that's a minor detail.)
RealtimeKit and the audio problem Posted Jul 3, 2009 17:01 UTC (Fri) by nedko (subscriber, #59419) [Link]
Maybe i misread something but "the app" was mentioned, not a tiny launcher executable. And yes, I know about set_rlimits.
Anyway, I just wanted to be helpful. I don't want to argue over set_rlimits like approach.
|
|||||||||||||