torbenh(a)gmx.de writes: Clever idea, but contrary to the POSIX standard for exec()... Similarly, if the set-group-ID mode bit of the new process image file is set, the effective group ID of the new process image shall be set to the group ID of the new process image file. The real user ID, real group ID, and supplementary group IDs of the new process image shall remain the same as those of the calling process image[1]. [1] http://www.opengroup.org/onlinepubs/007904975/functions/exec.html When the standard says "shall be set", it means they're not kidding. :-) Among other things, this would cause the process to have the wrong file system access authority. For example, Debian defines a group `audio' which has access to the sound devices. It would be natural to grant this group realtime privileges, but with your hack such programs would lose access to those devices (unless the user also belongs to group `audio'). If you accept my arguments why this is not the right solution, then the question remains, what to do about GTK-2? I don't suppose the GTK developers are likely to take the test out just because we ask them. In our case, this test has the unintended result of making system security worse rather than better. I personally think their test is wrong-headed except in the case of setuid to root, which may make sense. Is there some reasonable way to work around it? There is the obvious application-level hack of resetting the gid to the real value and then restoring it to the saved value around the call to gtk_init(). I consider this unworkable in practice, since it would have to be done in *every* realtime application using GTK. Without wholesale changes of this nature our realtime group LSM approach becomes relatively useless. I just removed an internal test for `has_capabilities', which was getting in the way of a workaround for some problems creating realtime POSIX threads under Linux. I don't think the test was needed in the first place, and it was getting in the way when the needed capabilities are present, but not via `jackstart'. I completely agree that my supplementary groups idea is less secure than the setgid approach. I was just trying to find *something* that would actually work. I didn't think of your e_gid hack above, which I admire though I do not accept it. Maybe we can come up with another, better idea. I wasn't either. Unfortunately, for reasons I still cannot explain (but see below) it now seems to be needed. It is possible that I just failed to notice earlier that mlockall() had failed. The symptoms of that failure are much more subtle than failure to gain SCHED_FIFO privileges. Unless the system is heavily loaded, the needed pages rarely get paged out. So, things may appear to run correctly for quite a while. In fact, I recommend making the mlockall() capabilities optional. For casual use, it will often be acceptable to run without them. A recent thread on linux-security-module(a)wirex.com underscores this point... Subject: PROBLEM: A Capability LSM Module serious bug Abstract When POSIX Capability LSM module isn't compiled into kernel, after inserting Capability module into kernel, all existed normal users processes will have total Capability privileges of superuser (root). It is possible that this may have contributed to my confusion about whether CAP_SYS_RESOURCE is really needed. Before seeing this message, I was already wondering if there are any free POSIX-compliance test suites available for Linux. We should really be running that with these modules, if we can. What do the kernel developers use? -- joq

On Mon, Dec 08, 2003 at 11:38:55AM -0800, Tim Hockin wrote: GTK has been like that for years now. Check the archives of SLASH'EM, a Nethack clone, for lots of back and forth. In short, they're not going to change. Jesper

On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote: Their explanation is here: http://www.gtk.org/setuid.html They've met a lot of resistance and not backed down yet; I seriously doubt they will. Therefore, coding around it in a consistent way will be necessary. I'll dig in my archives and see what I can find ... although I'm not sure an of it is useful. Jesper

On Tue, 2003-12-09 at 09:08, Clemens Ladisch wrote: If the GUI is not running in realtime, then things like changing the patch number from the midi stream won't be reflected instantaniously on screen. To the contrary: You can almost imagine SuperMario running up and down the interface with his little brushes, slowly repainting each and every knob and slider :-) This happens even if the realtime audio engine is near idle. The audio engine can still have priority over the GUI. That is to say: The GUI is another realtime process albeit with a much lower priority (than the audio engine.) cheers // Jens M Andreasen

i think this is sort of absurd. yes, technically its true but "much lower priority" means "so much lower" that talking about the GUI as though its RT doesn't make any sense. look, there are only 60-80 *physical* redraws of a monitor screen per second. you have, therefore, *at least* 1/100 of a second before you've "missed" a "graphics deadline". not only that, but because of the properties of the human visual system, missing the deadline won't matter in anything like the way missing an audio deadline does. this has none of the characteristics of "real time" from my perspective. now, if the audio thread is burning so much CPU time that the GUI doesn't get to run, its certainly a problem. but step back - is it a problem you want to fix by raising the priority of the GUI thread so that it steals time from the audio thread? or even from a "disk butler" thread. no, i don't think so. it simply means that the user is asking too much from their current hardware (and/or that the s/w is badly implemented, but thats a different story). do you want the GUI thread to have higher priority than cron? sure. but if cron running is causing super mario to be a little sluggish, you've got deeper problems to solve first. --p

On Wed, 2003-12-10 at 21:24, Benno Senoner wrote: -<snipped>- > So in conclusion I'd say: don't run your disk butlers SCHED_FIFO/RR but > use nice(-10) or something alike. > Same for GUIs if you care about reaction speed of the GUI run it > nice(-10) because with nice you don't risk hogging > the machine because of a slow gfx card/drivers or because of a > suboptimal redrawing implementation. Now that I have moved up from gtk to gtk2, I can follow your advice :) cheers // Jens M Andreasen

no, i'd call it an error in the toolkit or your own code. i have no idea which. what version of GTK+ are you using, and are they regular GTK+ sliders?

On Wed, 2003-12-10 at 15:45, Paul Davis wrote: The sluggish behaviour was with GTK-1.2 I have reasently changed to GTK-2.2 and pulled out my attempts at working around some of the shortcomings in 1.2 (slider values were upside down, mousewheel moved in the wrong direction) So I tried just now to take away SCHED_RR in the GUI. It works reasonably well. Problem solved :) cheers // Jens M Andreasen

torbenh(a)gmx.de writes: I only speak Texan, not English, but I'll be happy to compose a note. I'll post a draft here first, so y'all can critique it. ;-) -- joq

On Mon, Dec 08, 2003 at 11:38:55AM -0800, Tim Hockin wrote: I agree. This is definitely *not* any business for a graphical / windowing toolkit. This test should be removed. -- FA

Fernando Pablo Lopez-Lezcano &lt;nando(a)ccrma.stanford.edu&gt; writes: The setgid approach *is* a match on the realtime group. The question is which of several group IDs to you actually match against. Torben's jackcaps-0.2 checked only the effective group ID of the exec file. My current version checks others, too: the user's real and supplementary groups. Note that these are set by login, newgrp, etc. and are independent of the actual program being loaded. I'll append a copy to this message, so you can look at it. It's not ready to release yet. But, it seems to work for me. My current version supports all of these. The problem we have been discussing today is that option c) does not work for GTK applications. Since this is actually the most secure of the three options, that seems regrettable. I think the GTK developers made a mistake. When dealing with system security they seem to be operating outside their area of expertise. Of course, the same could be said for most of us. ;-) My current prototype is called `realtime', not `jackcapabilities', and has the following load-time options.. # modprobe realtime # `jackstart' capabilities only # modprobe realtime any=1 # option a) # modprobe realtime gid=29 # options b) and c) I plan to to add another option, mlock=0, for people who don't feel the need for locking storage. With this option, I would only grant CAP_SYS_NICE. I believe there are cases where this is sufficient. -- joq

Fernando Pablo Lopez-Lezcano &lt;nando(a)ccrma.stanford.edu&gt; writes: Right. GTK complains if its executable uses either setuid or setgid. This is regrettable, because setgid is more secure than assigning a set of users to the group. With setgid it is possible to restrict realtime privileges to a known set of programs. Otherwise, any program the privileged users execute can hang the system. I'm just fooling around with this stuff in my spare time right now. I made a 2.4.23-rc5 kernel patch to implement the /proc/sys/kernel interfaces we discussed. But, then I decided to check out 2.6 to see what can be done with the new LSM framework. That seems like the more important question. We already have 2.4 solutions via the capabilities patch. I expect a lot of audio users will migrate to 2.6 once it's released (pretty soon). Of course, your decisions and AGNULA's will have a big effect on that. This enables capabilities processing, equivalent to the 2.4 kernel capabilities patch. A program with appropriate privileges (including CAP_SETPCAP) can assign realtime privileges to other processes. So, your `jackstart' program works without requiring a kernel patch. Not right now. I haven't discovered a way to add an entry to /proc without patching the kernel, and I don't want to do that. There is a new `sysfs' in 2.6 that seems to allow similar kinds of dynamic control. I haven't figured out how to use that yet. The load time access is not so bad. You can rmmod and then reload the LSM if you want to change its parameters. I've been doing that a lot for testing. This has no effect on processes that are already running. -- joq

Just asking, I guess it is not really needed, just unloading and loading should be enough. It would be nice to have some sort of confirmation from /proc that the module is there and which options are active. Maybe that information is available somewhere after the module is loaded. -- Fernando

On Tue, Dec 09, 2003 at 01:05:51PM -0600, Jack O'Quin wrote: setting up a proc readable file is not so hard. but we could also printk it on module load. but then it will become more complicated: dmesg | grep "Realtime Security:" | tail -n 1 -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Wed, Dec 10, 2003 at 09:11:44PM -0800, Tim Hockin wrote: well there seems to be enough in the kernel itself... but anyway: yes please.. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Thu, Dec 11, 2003 at 09:15:50AM -0600, Jack O'Quin wrote: Here is some of the boilerplate code we used. Also have code to make a proc dir and use it, so instead of /proc/realtime or what not, you could have /proc/realtime/a, /proc/realtime/b, etc. Also have code to do a read/write proc file. These are against linux-2.4. Haven't played with proc on 2.6, yet. #include <linux/proc_fs.h> #ifdef CONFIG_PROC_FS static struct proc_dir_entry *proc_foo; #endif init(...) { ... #ifdef CONFIG_PROC_FS proc_foo = create_proc_read_entry("foo", 0, NULL, foo_read_proc, NULL); if (!proc_foo { printk(KERN_ERR "can't create /proc/foo\n"); } #endif ... } cleanup(...) { ... remove_proc_entry("foo", NULL); ... } #ifdef CONFIG_PROC_FS static int foo_read_proc(char *buf, char **start, off_t pos, int len, int *eof, void *x) { int plen; plen = sprintf(buf, "%s\n", foo); /* trying to read a bad offset? */ if (pos >= plen) { *eof = 1; return 0; } /* did we write everything we wanted to? */ if (len >= (plen-pos)) { *eof = 1; } *start = buf + pos; plen -= pos; return (len > plen) ? plen : len; } #endif

Tim Hockin &lt;thockin(a)hockin.org&gt; writes: Roger Larsson has an rt_monitor program that can do most of what you suggest. It also limits the fraction of the CPU these threads are allowed to consume. But, it can't handle mlockall(), and that's a show-stopper for some (but not all) serious audio uses. Right. And it doesn't help when the program wants to create a realtime thread later, like all JACK and PortAudio applications do. -- joq