At Fri, 26 Nov 2010 14:10:54 +0200, Dave Plater wrote:
On 11/26/2010 01:49 PM, Takashi Iwai wrote:
At Tue, 23 Nov 2010 20:16:52 +0200, Dave Plater wrote:
On 11/23/2010 04:16 PM, Ludwig Nussel wrote:
Dave Plater wrote:
On 11/22/2010 04:25 PM, Ludwig Nussel wrote:
> This is stated at http://jackaudio.org/faq and I didn't have sound from > jack without it, I've had those lines for a while. Obviously the user > has to be a member of the audio group. I'm looking for a macro to > > > I'd veto such abuse of the audio group. The jack daemon needs to be started with appropriate privileges, ie either by a supervising root process or via setuid/fscaps.
As jack is started and run as user, how would you propose to grant jack real time scheduling?
Just as cited above :-) Either some root process needs to start jackd as the intended user with the necessary privileges (e.g. via DBus) or you need to make jackd setuid root/grant fscaps. If jackd isn't prepared to run that way you could also write a small wrapper for that purpose. In any case the security team wants to review such things prior to inclusion in Factory.
cu Ludwig
Ok I'm beginning to understand what jack dbus is all about, unfortunately most packages that use jack still depend on jack classic and although jack can build with both interfaces it does so with a warning and although it works when I test it, I don't trust it. I will research the various options, making a jack that just works is on my todo list but not that urgent.
The approach using limits.conf is some how compromise for easiness and reliability in the past. Before that, a wrapper approach was taken. You can find some codes in jack 0.9.x.
When only concerning about usability, adding these limits automatically is the easiest option, of course. But, this will most likely anger security guys :)
Using rtkit would be a good option This looks promising, I'll look into it.
, especially for JACK2, I guess. I haven't followed the recent development, so I have no idea whether this is being discussed / implemented, though. Other than that, I'd say to keep the thing as is, and provide a good documentation, at least, README.SUSE or such, for informing users this small bit.
Adding two lines manually isn't too difficult, and user should know the risk as well by that.
thanks,
Takashi
Ok then a compromise is using echo "instructions" in %post, is this acceptable?
Well, I doubt anyone will read it so much. During installation in GUI, the messages are hidden by slide shows.
I should imagine that jack dbus overcomes this hurdle but it will take a while for the applications that use jack to use it.
Yeah, I think no solid solution is in sight yet. But tools are ready, so it depends on the upstream developer. thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org