[opensuse-packaging] Is there an easy way to add to /etc/security/limits.conf in %post?
Hi, jack requires two lines in "/etc/security/limits.conf" in order to work properly, is there an easy way to add them to the file? The lines are : @audio - rtprio 99 @audio - memlock unlimited Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dave Plater wrote:
Hi, jack requires two lines in "/etc/security/limits.conf" in order to work properly, is there an easy way to add them to the file? The lines are : @audio - rtprio 99 @audio - memlock unlimited
Isn't jack a sound daemon? Those lines only have an effect for members of the audio group if pam is used to open a session. Where is the relation to jack here? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11/22/2010 02:06 PM, Ludwig Nussel wrote:
Dave Plater wrote:
Hi, jack requires two lines in "/etc/security/limits.conf" in order to work properly, is there an easy way to add them to the file? The lines are : @audio - rtprio 99 @audio - memlock unlimited
Isn't jack a sound daemon? Those lines only have an effect for members of the audio group if pam is used to open a session. Where is the relation to jack here?
cu Ludwig
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 perform the task. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dave Plater wrote:
On 11/22/2010 02:06 PM, Ludwig Nussel wrote:
Dave Plater wrote:
Hi, jack requires two lines in "/etc/security/limits.conf" in order to work properly, is there an easy way to add them to the file? The lines are : @audio - rtprio 99 @audio - memlock unlimited
Isn't jack a sound daemon? Those lines only have an effect for members of the audio group if pam is used to open a session. Where is the relation to jack here?
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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11/22/2010 04:25 PM, Ludwig Nussel wrote:
Dave Plater wrote:
On 11/22/2010 02:06 PM, Ludwig Nussel wrote:
Dave Plater wrote:
Hi, jack requires two lines in "/etc/security/limits.conf" in order to work properly, is there an easy way to add them to the file? The lines are : @audio - rtprio 99 @audio - memlock unlimited
Isn't jack a sound daemon? Those lines only have an effect for members of the audio group if pam is used to open a session. Where is the relation to jack here?
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.
cu Ludwig
jackd is normally started by the users application that uses it or it can be started via the command line by a user and if it's not used it times out and exits by itself. IOW it's not like a normal daemon that carries on once started by root until it's stopped. If root starts jack it works without the above lines but users are the users not root. I thought that it would be nice for a first time openSUSE user to find out that jack just works without the normal tweaking but if it's such an issue I'll leave it alone. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11/22/2010 04:25 PM, Ludwig Nussel wrote:
Dave Plater wrote:
On 11/22/2010 02:06 PM, Ludwig Nussel wrote:
Dave Plater wrote:
Hi, jack requires two lines in "/etc/security/limits.conf" in order to work properly, is there an easy way to add them to the file? The lines are : @audio - rtprio 99 @audio - memlock unlimited
Isn't jack a sound daemon? Those lines only have an effect for members of the audio group if pam is used to open a session. Where is the relation to jack here?
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.
cu Ludwig
As jack is started and run as user, how would you propose to grant jack real time scheduling? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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, 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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? I should imagine that jack dbus overcomes this hurdle but it will take a while for the applications that use jack to use it. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
* Dave Plater (davejplater@gmail.com) [20101126 13:11]:
> Could the quoting possibly cut down a bit? Six levels is rather ridiculous.
Ok then a compromise is using echo "instructions" in %post, is this acceptable?
That would be of no use as it'll only be shown when installing from the command line. Takashi's suggestion of using a README.SUSE would be much better. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 26 Nov 2010, Philipp Thomas wrote:
* Dave Plater (davejplater@gmail.com) [20101126 13:11]:
>> Could the quoting possibly cut down a bit? Six levels is rather ridiculous.
Ok then a compromise is using echo "instructions" in %post, is this acceptable?
That would be of no use as it'll only be shown when installing from the command line. Takashi's suggestion of using a README.SUSE would be much better.
Would it be possible to also add this information to the man-page and/or to the internal usage infomation ( --help ). Maybe ask upstream to include this info to the troubleshooting tips. How does one getting Jack to work properly in RedHat/Fedora, Mandrivia, or even Debian/Ubuntu. IS there even a consens, or does ervey distro their own thing? I'm just searching for a common solution for all the Jack using distros. A suid/filecap-wrapper in /usr/bin to start jack as a normal user with the needed rights/prio/sheduling, and the deamon itself residing in /usr/sbin would be the most universally secure and practicable solution in my eyes. This would keep the user clean in terms of security and ease of use, and provide a working solution out of the box with no extras (e.g. inserts to /etc/security/limits.conf) to maintain. Please correct me if I'm wrong here. Feel free to use this as a discussion / implemention base. With best wishes, Michael Foerster. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Would it be possible to also add this information to the man-page and/or to the internal usage infomation ( --help ).
Maybe ask upstream to include this info to the troubleshooting tips.
How does one getting Jack to work properly in RedHat/Fedora, Mandrivia, or even Debian/Ubuntu. IS there even a consens, or does ervey distro their own thing?
I'm just searching for a common solution for all the Jack using distros.
A suid/filecap-wrapper in /usr/bin to start jack as a normal user with the needed rights/prio/sheduling, and the deamon itself residing in /usr/sbin would be the most universally secure and practicable solution in my eyes.
This would keep the user clean in terms of security and ease of use, and provide a working solution out of the box with no extras (e.g. inserts to /etc/security/limits.conf) to maintain.
Please correct me if I'm wrong here. Feel free to use this as a discussion / implemention base.
With best wishes, Michael Foerster. ATM you have to ask or look at jack faqs to get jack to work in all the distros afaik. I'm making an effort to try and change that. I like the man page idea and I will try to put some info in there, it will be good sed practice for me. A wrapper isn't really an option as jack is normally started by the application that uses it. An experienced user
On 11/26/2010 07:25 PM, Michael Foerster wrote: that starts jack and sets up connections wouldn't need to know about how to grant jack real time rights. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 26 Nov 2010, Dave Plater wrote:
On 11/26/2010 07:25 PM, Michael Foerster wrote:
<snip> A suid/filecap-wrapper in /usr/bin to start jack as a normal user with the needed rights/prio/sheduling, and the deamon itself residing in /usr/sbin would be the most universally secure and practicable solution in my eyes.
ATM you have to ask or look at jack faqs to get jack to work in all the distros afaik. I'm making an effort to try and change that. I like the man page idea and I will try to put some info in there, it will be good sed practice for me. A wrapper isn't really an option as jack is normally started by the application that uses it. An experienced user that starts jack and sets up connections wouldn't need to know about how to grant jack real time rights.
The question is how does an application start jack. If the applikation is started as an normal user there's no /sbin/ nor /usr/sbin/ in the path so the wrapper in /usr/bin would be used to start the real jackd binary with the needed rights. If the app calls /usr/sbin/jackd directly, the better approach would be to move the jackd binary to /usr/sbin/jackd-bin and install or symlink the wrapper as /usr/sbin/jackd in addition to /usr/bin/jackd. That would handle both cases. The real question is what can be doen to 'automatize' the need right-granting without the need to patch any other app. An other question is this scenario: If one grants the rights in /etc/security/limits.conf to the audio group, and the user is a member of this group, and the audio-app and jackd are installed as group audio, what rights / prio / sheduling will have any other app? E.g. Firefox with Flash, which also uses audio-out? Do we open up a security hole? I'm just asking, because I'm not sure what will happen. Ciao, Michael Foerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
An other question is this scenario: If one grants the rights in /etc/security/limits.conf to the audio group, and the user is a member of this group, and the audio-app and jackd are installed as group audio, what rights / prio / sheduling will have any other app? E.g. Firefox with Flash, which also uses audio-out?
Do we open up a security hole? I'm just asking, because I'm not sure what will happen.
Ciao, Michael Foerster I think that you've just explained the concerns raised earlier on in
On 11/26/2010 09:06 PM, Michael Foerster wrote: this thread. I'm still digesting your other suggestions. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
At Fri, 26 Nov 2010 20:06:13 +0100 (CET), Michael Foerster wrote:
On Fri, 26 Nov 2010, Dave Plater wrote:
On 11/26/2010 07:25 PM, Michael Foerster wrote:
<snip> A suid/filecap-wrapper in /usr/bin to start jack as a normal user with the needed rights/prio/sheduling, and the deamon itself residing in /usr/sbin would be the most universally secure and practicable solution in my eyes.
ATM you have to ask or look at jack faqs to get jack to work in all the distros afaik. I'm making an effort to try and change that. I like the man page idea and I will try to put some info in there, it will be good sed practice for me. A wrapper isn't really an option as jack is normally started by the application that uses it. An experienced user that starts jack and sets up connections wouldn't need to know about how to grant jack real time rights.
The question is how does an application start jack. If the applikation is started as an normal user there's no /sbin/ nor /usr/sbin/ in the path so the wrapper in /usr/bin would be used to start the real jackd binary with the needed rights. If the app calls /usr/sbin/jackd directly, the better approach would be to move the jackd binary to /usr/sbin/jackd-bin and install or symlink the wrapper as /usr/sbin/jackd in addition to /usr/bin/jackd. That would handle both cases.
The real question is what can be doen to 'automatize' the need right-granting without the need to patch any other app.
An other question is this scenario: If one grants the rights in /etc/security/limits.conf to the audio group, and the user is a member of this group, and the audio-app and jackd are installed as group audio, what rights / prio / sheduling will have any other app? E.g. Firefox with Flash, which also uses audio-out?
Do we open up a security hole?
The proper limits.conf provide only a limited resource for RT and memory-lock, thus in general, this shouldn't result in a complete system-down. But, this gives far more rights than normal, so anything weird could be triggered, in theory, yes. The limits.conf solution is pretty easy, but it's not fine-grained enough. So, no distros (except for audio-specific ones) don't want set it as default. Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Dave Plater -
Ludwig Nussel -
Michael Foerster -
Philipp Thomas -
Takashi Iwai