On Thu, 12 Jul 2007, pd-list-request@iem.at wrote:
would it be possible to add an option to ask the user if he wants to chmod +s pd? some people told me it's dangerous. is it really? pd is already a powerful (read dangerous) software with the objet system, shell or netreceive...
Last year I demonstrated that it is possible to make a very small external that gives root access to the whole pd process. This vulnerability only affects Miller's pd, including pd-0.41-0test04 (which is the absolute latest). I have fixed that problem during devel_0_39 and carried it into the desiredata branch.
This problem is largely theoretical so far, as it requires an external to play with the setuid/seteuid commands. I can't think of any external that does that, except the small test that I made for the purpose of verifying my claim.
I haven't looked much for other possible breaches of root access.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Jul 12, 2007, at 3:18 PM, Mathieu Bouchard wrote:
On Thu, 12 Jul 2007, pd-list-request@iem.at wrote:
would it be possible to add an option to ask the user if he wants
to chmod +s pd? some people told me it's dangerous. is it really?
pd is already a powerful (read dangerous) software with the objet
system, shell or netreceive...Last year I demonstrated that it is possible to make a very small
external that gives root access to the whole pd process. This
vulnerability only affects Miller's pd, including pd-0.41-0test04
(which is the absolute latest). I have fixed that problem during
devel_0_39 and carried it into the desiredata branch.This problem is largely theoretical so far, as it requires an
external to play with the setuid/seteuid commands. I can't think of
any external that does that, except the small test that I made for
the purpose of verifying my claim.I haven't looked much for other possible breaches of root access.
This is only possible if you are running Pd as root, which is general
is not a good idea. If Pd is running as a different user, then you
wouldn't be able to gain root access.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jul 12, 2007, at 3:18 PM, Mathieu Bouchard wrote:
Last year I demonstrated that it is possible to make a very small
external that gives root access to the whole pd process. This
vulnerability only affects Miller's pd, including pd-0.41-0test04
(which is the absolute latest). I have fixed that problem during
devel_0_39 and carried it into the desiredata branch.This problem is largely theoretical so far, as it requires an
external to play with the setuid/seteuid commands. I can't think of
any external that does that, except the small test that I made for
the purpose of verifying my claim.I haven't looked much for other possible breaches of root access.
This is only possible if you are running Pd as root, which is general
is not a good idea. If Pd is running as a different user, then you
wouldn't be able to gain root access.
Matju can comment better, but AFAIR in my tests his external also worked with a setuid root Pd started as a normal user. You can check this with the code, it's somewhere in the bug tracker.
Anyways, making /usr/bin/pd setuid is not necessary anyway, as I wrote in another mail.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jul 12, 2007, at 6:52 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jul 12, 2007, at 3:18 PM, Mathieu Bouchard wrote:
Last year I demonstrated that it is possible to make a very small external that gives root access to the whole pd process. This vulnerability only affects Miller's pd, including pd-0.41-0test04 (which is the absolute latest). I have fixed that problem during devel_0_39 and carried it into the desiredata branch.
This problem is largely theoretical so far, as it requires an external to play with the setuid/seteuid commands. I can't think of any external that does that, except the small test that I made for the purpose of verifying my claim.
I haven't looked much for other possible breaches of root access.
This is only possible if you are running Pd as root, which is general is not a good idea. If Pd is running as a different user, then you wouldn't be able to gain root access.
Matju can comment better, but AFAIR in my tests his external also worked with a setuid root Pd started as a normal user. You can check this with the code, it's somewhere in the bug tracker.
Anyways, making /usr/bin/pd setuid is not necessary anyway, as I wrote in another mail.
"setuid root" means that the process will always run as root, no
matter who starts it. So it's the same as running pd as root.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Pd does a "seteuid(setuid())" to un-get root priveliges if run as setuid, after its priority gets promoted, so that it runs as the user who started it. But there are apparently loopholes, as Mathieu has found.
I'm trying to repeat Frank's trick with /etc/security/limits.conf, so far without success, but if that works it would be much preferable to making Pd setuid root.
cheers Miller
On Thu, Jul 12, 2007 at 10:40:49PM -0400, Hans-Christoph Steiner wrote:
On Jul 12, 2007, at 6:52 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jul 12, 2007, at 3:18 PM, Mathieu Bouchard wrote:
Last year I demonstrated that it is possible to make a very small external that gives root access to the whole pd process. This vulnerability only affects Miller's pd, including pd-0.41-0test04 (which is the absolute latest). I have fixed that problem during devel_0_39 and carried it into the desiredata branch.
This problem is largely theoretical so far, as it requires an external to play with the setuid/seteuid commands. I can't think of any external that does that, except the small test that I made for the purpose of verifying my claim.
I haven't looked much for other possible breaches of root access.
This is only possible if you are running Pd as root, which is general is not a good idea. If Pd is running as a different user, then you wouldn't be able to gain root access.
Matju can comment better, but AFAIR in my tests his external also worked with a setuid root Pd started as a normal user. You can check this with the code, it's somewhere in the bug tracker.
Anyways, making /usr/bin/pd setuid is not necessary anyway, as I wrote in another mail.
"setuid root" means that the process will always run as root, no
matter who starts it. So it's the same as running pd as root..hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Pd does a "seteuid(setuid())" to un-get root priveliges if run as setuid, after its priority gets promoted, so that it runs as the user who started it. But there are apparently loopholes, as Mathieu has found.
I'm trying to repeat Frank's trick with /etc/security/limits.conf, so far without success, but if that works it would be much preferable to making Pd setuid root.
Here it works for several months at least:
(~)-$ ls -l /usr/bin/pd -rwxr-xr-x 1 root root 809768 May 31 19:05 /usr/bin/pd (~)-$ /usr/bin/pd -rt priority 8 scheduling enabled. priority 6 scheduling enabled.
Debian with libpam-modules 0.79-4.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jul 13, 2007, at 1:43 AM, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Pd does a "seteuid(setuid())" to un-get root priveliges if run as setuid, after its priority gets promoted, so that it runs as the user who started it. But there are apparently loopholes, as Mathieu has found.
I'm trying to repeat Frank's trick with /etc/security/limits.conf, so far without success, but if that works it would be much preferable to making Pd setuid root.
Here it works for several months at least:
(~)-$ ls -l /usr/bin/pd -rwxr-xr-x 1 root root 809768 May 31 19:05 /usr/bin/pd (~)-$ /usr/bin/pd -rt priority 8 scheduling enabled. priority 6 scheduling enabled.
Debian with libpam-modules 0.79-4.
I wonder how to set up something like this in a package. Too bad
there isn't something like /etc/security.d/, where packages can
install things. Anyone have any ideas along that line? I guess one
answer is to use Ubuntu Studio... ;)
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hans-Christoph Steiner wrote:
On Jul 13, 2007, at 1:43 AM, Frank Barknecht wrote:
Debian with libpam-modules 0.79-4.
I wonder how to set up something like this in a package. Too bad
i daresay you don't.
how about adding documentation to the README that explain how to setup the /etc/security/limits.conf just for the archives i repeat the steps: make sure, your /etc/security/limits.conf holds these 3 lines: @audio - rtprio 99 @audio - memlock 250000 @audio - nice -10
imho, it would be not such a good idea to do that in the package-setup, at least _without asking_ the user whether they really want that. even though the adding these lines is far from as dangerous as the setuid(), it still imposes the risk of anyone being a member of group audio to freeze the computer, which - to my knowledge - is a "security risk".
if you do think that it is too much, to ask people to read the readme and do it yourself, you could use debconf (on debian/ubuntu) to ask the user whether they really want that. on non-debian systems i don't know, but surely there are mechanisms that allow the same.
there isn't something like /etc/security.d/, where packages can
install things. Anyone have any ideas along that line? I guess one
the problem is, that /etc/security/limits.conf is not a per-application but a per-user (including per-group) setting. so it does have side-effects, which is probably the reason why there is no such thing as you asked for.
fmgasd.r IOhannes
IOhannes m zmoelnig wrote:
just for the archives i repeat the steps: make sure, your /etc/security/limits.conf holds these 3 lines:
oops, should have read the entire thread before answering. so i know that frank has already posted this (i thought that miller was probably referring to an older post which i had missed)
mgfa.sdr IOhannes
Aha, on the next boot it worked. Thanks!
Miller
On Fri, Jul 13, 2007 at 07:43:10AM +0200, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Pd does a "seteuid(setuid())" to un-get root priveliges if run as setuid, after its priority gets promoted, so that it runs as the user who started it. But there are apparently loopholes, as Mathieu has found.
I'm trying to repeat Frank's trick with /etc/security/limits.conf, so far without success, but if that works it would be much preferable to making Pd setuid root.
Here it works for several months at least:
(~)-$ ls -l /usr/bin/pd -rwxr-xr-x 1 root root 809768 May 31 19:05 /usr/bin/pd (~)-$ /usr/bin/pd -rt priority 8 scheduling enabled. priority 6 scheduling enabled.
Debian with libpam-modules 0.79-4.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
Aha, on the next boot it worked. Thanks!
as pam is login-related, all changes to it's configuration only take effect after a fresh login. (like when you add yourself to another group, you will have to re-login in order to be really part of the group).
no need for rebooting though.
fmgas.dr IOhannes
Can anyone make a wiki page about this on http://puredata.org/docs ?
It would be quite handy to have.
Also, I'd love to hear suggestions how to make this part of the Pd-
extended package. I think it makes a lot of sense to have this a
debconf question. I suppose setuid could be a debconf question as well.
.hc
On Jul 13, 2007, at 12:32 PM, Miller Puckette wrote:
Aha, on the next boot it worked. Thanks!
Miller
On Fri, Jul 13, 2007 at 07:43:10AM +0200, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Pd does a "seteuid(setuid())" to un-get root priveliges if run as setuid, after its priority gets promoted, so that it runs as the user who started it. But there are apparently loopholes, as Mathieu has found.
I'm trying to repeat Frank's trick with /etc/security/ limits.conf, so far without success, but if that works it would be much preferable to making Pd setuid root.
Here it works for several months at least:
(~)-$ ls -l /usr/bin/pd -rwxr-xr-x 1 root root 809768 May 31 19:05 /usr/bin/pd (~)-$ /usr/bin/pd -rt priority 8 scheduling enabled. priority 6 scheduling enabled.
Debian with libpam-modules 0.79-4.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Can anyone make a wiki page about this on http://puredata.org/docs ?
It would be quite handy to have.Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a
debconf question. I suppose setuid could be a debconf question as well.
I *really* don't think, that every audio software on the planet should try to setup a user's system for a certain way of realtime operation. If at all, this should be done only by the package libpam-modules or maybe by some meta-package (e.g. "realtime-desktop") that the puredata package could recommend.
The rlimits approach will soon be common knowledge among all Linux audio users anyway.
Adding a note to /usr/share/doc/puredata/README.Debian would be something to consider, of course.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote: [...]
its astonishing, how often we agree...
mfga.sdr IOhannes
On Jul 14, 2007, at 2:16 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Can anyone make a wiki page about this on http://puredata.org/docs ? It would be quite handy to have.
Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a debconf question. I suppose setuid could be a debconf question as
well.I *really* don't think, that every audio software on the planet should try to setup a user's system for a certain way of realtime operation. If at all, this should be done only by the package libpam-modules or maybe by some meta-package (e.g. "realtime-desktop") that the puredata package could recommend.
The rlimits approach will soon be common knowledge among all Linux audio users anyway.
Adding a note to /usr/share/doc/puredata/README.Debian would be something to consider, of course.
If someone writes that README, I'll happily add it to the package. I
think that "docs" or "packages/linux_make" could work as a place in
CVS for it.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Jul 14, 2007, at 2:16 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Can anyone make a wiki page about this on http://puredata.org/docs ? It would be quite handy to have.
Also, I'd love to hear suggestions how to make this part of the Pd- extended package. I think it makes a lot of sense to have this a debconf question. I suppose setuid could be a debconf question as
well.I *really* don't think, that every audio software on the planet should try to setup a user's system for a certain way of realtime operation. If at all, this should be done only by the package libpam-modules or maybe by some meta-package (e.g. "realtime-desktop") that the puredata package could recommend.
I am interested in the result rather than how it is implemented. If
that was a bad idea, are there any others? I think it is important
that the Pd packages work well after installing without having to
tweak it, including having glitch-free audio after installing. It
works like this with many programs on Mac OS X, I think it should
work the same on GNU/Linux.
The rlimits approach will soon be common knowledge among all Linux audio users anyway.
Not everyone wants to learn about this stuff. Some people just want
to install Ubuntu Studio and make music. It would like to support
that impulse. I think that is possible without restricting people
from getting deeper.
.hc
Adding a note to /usr/share/doc/puredata/README.Debian would be something to consider, of course.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
The rlimits approach will soon be common knowledge among all Linux
audio users anyway.
Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music.
hans, i am so much on your side here. ..although i'd say: 'some of us just want to install ubuntu studio, make massively complicated pd patches, and then make music.'
Hallo, hard off hat gesagt: // hard off wrote:
The rlimits approach will soon be common knowledge among all Linux
audio users anyway.
Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music.
hans, i am so much on your side here. ..although i'd say: 'some of us just want to install ubuntu studio, make massively complicated pd patches, and then make music.'
Others want to make massive 36-channel recordings with Ardour, run 128-voice synthesiziers with SuperCollider, rock the party with Mixxx, play Csound5 in realtime, edit midi arrangements with MusE, run a live webradio stream with icecast2 while OTOH others want to harden their webserver with port-knock logins or set fierce limits for all users. Should all these packages fight for who should edit limits.conf and whose edits will finally survive?
This is not about if users should learn how to edit limits.conf or not, this is about playing fair with other pieces of software installed in a distribution.
If it was only about making editing limits.conf easier, here's a way: Just run this script as root/under sudo:
#!/bin/sh if test -w /etc/security/limits.conf then read -p "Update /etc/security/limits.conf? [yN]: " DOIT if test "$DOIT" = "y" then echo "@audio - nice -10" >> /etc/security/limits.conf echo "@audio - rtprio 99" >> /etc/security/limits.conf echo "@audio - memlock unlimited" >> /etc/security/limits.conf echo "/etc/security/limits.conf updated successfully!" echo "You need to logout completely and login again to" echo "activate changes." echo "Also make sure you're in group "audio"." else echo "Okay, doing nothing" fi else echo "/etc/security/limits.conf not writable, giving up" fi
# EOF
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I think it's best to put this on the wiki as a possible tweak. There are too many 'reasonable' variations. For instance, on personal machines I use my own login name instead of a group 'audio' (for simplicity); also, I don't touch the 'nice' settings.
I've never had stability problems with "-rt" and use it in all my routine work. My idea is to make my development environment exactly the same as the performance environment to reduce the chance of surprises. However, if you're in the habit of having Pd spawn sub-processes, "-rt" is dangerous. I'm not sure if "renicing" is safe or not; I never do it myself, preferring to count on the RTPRIO setting to take care of things.
cheers Miller
On Wed, Jul 18, 2007 at 06:52:11PM +0200, Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
The rlimits approach will soon be common knowledge among all Linux
audio users anyway.
Not everyone wants to learn about this stuff. Some people just want to install Ubuntu Studio and make music.
hans, i am so much on your side here. ..although i'd say: 'some of us just want to install ubuntu studio, make massively complicated pd patches, and then make music.'
Others want to make massive 36-channel recordings with Ardour, run 128-voice synthesiziers with SuperCollider, rock the party with Mixxx, play Csound5 in realtime, edit midi arrangements with MusE, run a live webradio stream with icecast2 while OTOH others want to harden their webserver with port-knock logins or set fierce limits for all users. Should all these packages fight for who should edit limits.conf and whose edits will finally survive?
This is not about if users should learn how to edit limits.conf or not, this is about playing fair with other pieces of software installed in a distribution.
If it was only about making editing limits.conf easier, here's a way: Just run this script as root/under sudo:
#!/bin/sh if test -w /etc/security/limits.conf then read -p "Update /etc/security/limits.conf? [yN]: " DOIT if test "$DOIT" = "y" then echo "@audio - nice -10" >> /etc/security/limits.conf echo "@audio - rtprio 99" >> /etc/security/limits.conf echo "@audio - memlock unlimited" >> /etc/security/limits.conf echo "/etc/security/limits.conf updated successfully!" echo "You need to logout completely and login again to" echo "activate changes." echo "Also make sure you're in group "audio"." else echo "Okay, doing nothing" fi else echo "/etc/security/limits.conf not writable, giving up" fi
# EOF
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I've never had stability problems with "-rt" and use it in all my routine work. My idea is to make my development environment exactly the same as the performance environment to reduce the chance of surprises. However, if you're in the habit of having Pd spawn sub-processes, "-rt" is dangerous. I'm not sure if "renicing" is safe or not; I never do it myself, preferring to count on the RTPRIO setting to take care of things.
My main reason to not run -rt normally is to avoid the risk of getting into a lockup when I do something wrong in my patch. ;)
A reason not to have it in .pdrc/.pdsettings is, that I often to run two Pds, one for Gem, one for audio. I prefer starting the audio Pd with -rt manually then, while the Gem-Pd won't run with -rt.
(I also run two Pds, because Gem with Mesa-DRI drivers crashes Pd when closing the gemwin, and often even without closing. By running two Pds I only loose half of my work.)
But anyway, I believe all this should be a choice of the user and not be predefined by the package.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi all,
I'm trying to get a game-controller (and eventually also the Wii-controller) up and running on pure data which I am currently running on windows. As I understand it the best object at the moment to tap into the datastreams produced by game controllers etc. is the HID-object build by Hans-Christoph Steiner. It isn't provided with the latest beta version of PD extended and I'm also beginning to believe that it doesn't even run on windows at all - is the right or wrong? If there is a windows-version of this/these objects could someone please point me to them?
Cheers! Thomas
Hi again,
I did some more research on the topic and found the solution for my problem in the "joystick"-object - thanks to a post by David Merrill - thank you for that :)
Still I'm looking forward to see what the HID-object can do when it comes out for windows, for example will it support the Wii-controller?
Cheers! Thomas
----- Original Message ----- From: "Thomas Jeppesen" Jeppesen@skydebanen.net To: pd-list@iem.at Sent: Wednesday, July 18, 2007 9:17 PM Subject: [PD] HID for PD on windows?
Hi all,
I'm trying to get a game-controller (and eventually also the Wii-controller) up and running on pure data which I am currently running on windows. As I understand it the best object at the moment to tap into the datastreams produced by game controllers etc. is the HID-object build by Hans-Christoph Steiner. It isn't provided with the latest beta version of PD extended and I'm also beginning to believe that it doesn't even run on windows at all - is the right or wrong? If there is a windows-version of this/these objects could someone please point me to them?
Cheers! Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.4/897 - Release Date: 11-07-2007 21:57
Sounds like a big buffer by default is the best option for the
package. Maybe something like 50ms, that should be big enough to
cover all but the really heinous hardware. Then docs about setting
up for tight timing, limits.conf, -rt, etc.
.hc
On Jul 18, 2007, at 2:03 PM, Miller Puckette wrote:
I think it's best to put this on the wiki as a possible tweak.
There are too many 'reasonable' variations. For instance, on personal
machines I use my own login name instead of a group 'audio' (for simplicity); also, I don't touch the 'nice' settings.I've never had stability problems with "-rt" and use it in all my
routine work. My idea is to make my development environment exactly the
same as the performance environment to reduce the chance of surprises.
However, if you're in the habit of having Pd spawn sub-processes, "-rt" is
dangerous. I'm not sure if "renicing" is safe or not; I never do it myself,
preferring to count on the RTPRIO setting to take care of things.cheers Miller
On Wed, Jul 18, 2007 at 06:52:11PM +0200, Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
The rlimits approach will soon be common knowledge among all Linux
audio users anyway.
Not everyone wants to learn about this stuff. Some people just
want to install Ubuntu Studio and make music.hans, i am so much on your side here. ..although i'd say:
'some of us just want to install ubuntu studio, make massively complicated pd
patches, and then make music.'Others want to make massive 36-channel recordings with Ardour, run 128-voice synthesiziers with SuperCollider, rock the party with
Mixxx, play Csound5 in realtime, edit midi arrangements with MusE, run a
live webradio stream with icecast2 while OTOH others want to harden their webserver with port-knock logins or set fierce limits for all users. Should all these packages fight for who should edit limits.conf and whose edits will finally survive?This is not about if users should learn how to edit limits.conf or not, this is about playing fair with other pieces of software installed in a distribution.
If it was only about making editing limits.conf easier, here's a way: Just run this script as root/under sudo:
#!/bin/sh if test -w /etc/security/limits.conf then read -p "Update /etc/security/limits.conf? [yN]: " DOIT if test "$DOIT" = "y" then echo "@audio - nice -10" >> /etc/security/limits.conf echo "@audio - rtprio 99" >> /etc/security/limits.conf echo "@audio - memlock unlimited" >> /etc/security/ limits.conf echo "/etc/security/limits.conf updated successfully!" echo "You need to logout completely and login again to" echo "activate changes." echo "Also make sure you're in group "audio"." else echo "Okay, doing nothing" fi else echo "/etc/security/limits.conf not writable, giving up" fi
# EOF
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I am interested in the result rather than how it is implemented. If
that was a bad idea, are there any others? I think it is important
that the Pd packages work well after installing without having to
tweak it, including having glitch-free audio after installing.
The issue is: Tweaking Pd is fine, but editing limits.conf is tweaking a very different part of the system. If I may exaggerate a teeny-tiny bit: I guess we would never consider to download, configure, compile and install a realtime-patched kernel while installing Pd, even though Pd would benefit from that.
Regarding getting glitch-free operation in Pd for "newbies": Just make a big buffer size the default, then nobody should get (too many) glitches even without realtime mode. As I wrote elsewhere, enabling -rt for Pd as default in my opinion is a bad idea, and without that startup setting, it doesn't matter at all what's in limits.conf. As I wrote there as well: Personally I never run "-rt" except in performances or rehearsals for performances.
It works like this with many programs on Mac OS X, I think it should work the same on GNU/Linux.
Things may have changed, but when I still had Windows, no audio application I installed has ever asked me if I would like to change the security settings of my system.
Not everyone wants to learn about this stuff. Some people just want
to install Ubuntu Studio and make music. It would like to support
that impulse. I think that is possible without restricting people
from getting deeper.
By all I know, Ubuntustudio, Jacklab, Pure:Dyne and 64Studio already have limits.conf set up accordingly.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
By all I know, Ubuntustudio, Jacklab, Pure:Dyne and 64Studio already have limits.conf set up accordingly.
Or actually: I didn't check, so maybe they haven't (except pure:dyne, which has), but it may be worth to take a look at how they do it, if they do it, and if they don't, maybe indeed suggest a meta-package that sets limits.conf. A puredata package as well as jackd, ardour etc. could then recommend this package.
Just doing this for limits.conf would be trivial, but such a "tweak-realtime" package could also include some other stuff, like setting interrupts, checking for preempt in the kernel etc.
But to reiterate: IMO this is not something a Pd package should even try to do itself, especially out of respect for the various distribution policies.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 12 Jul 2007, Hans-Christoph Steiner wrote:
This is only possible if you are running Pd as root, which is general is not a good idea. If Pd is running as a different user, then you wouldn't be able to gain root access.
We are *only* talking about setuid (chmod +s) and not starting pd from a root login.
If pd is running as user "eighthave" but with setuid "root", pd is dropping priviledges to be effectively just "eighthave", but does it the wrong way, causing it to be able to regain effective "root" later.
I reported this bug last november:
http://lists.puredata.info/pipermail/pd-dev/2006-11/007910.html
I have fixed that bug in devel_0_39 on 2006.11.23.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Jul 13, 2007, at 3:36 PM, Mathieu Bouchard wrote:
On Thu, 12 Jul 2007, Hans-Christoph Steiner wrote:
This is only possible if you are running Pd as root, which is
general is not a good idea. If Pd is running as a different user,
then you wouldn't be able to gain root access.We are *only* talking about setuid (chmod +s) and not starting pd
from a root login.If pd is running as user "eighthave" but with setuid "root", pd is
dropping priviledges to be effectively just "eighthave", but does
it the wrong way, causing it to be able to regain effective "root"
later.I reported this bug last november:
http://lists.puredata.info/pipermail/pd-dev/2006-11/007910.html
I have fixed that bug in devel_0_39 on 2006.11.23.
Sorry, I didn't see the part that it was just related to setuid.
It would be very nice to have this bug fix as a patch in the tracker
so that it can be included in pd-vanilla and pd-extended.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Access to computers should be unlimited and total. - the hacker ethic
On Sat, 14 Jul 2007, Hans-Christoph Steiner wrote:
On Jul 13, 2007, at 3:36 PM, Mathieu Bouchard wrote:
I reported this bug last november: http://lists.puredata.info/pipermail/pd-dev/2006-11/007910.html I have fixed that bug in devel_0_39 on 2006.11.23.
It would be very nice to have this bug fix as a patch in the tracker so that it can be included in pd-vanilla and pd-extended.
Well, I've already given you the date... here's the URL to the actual patch: http://lists.puredata.info/pipermail/pd-cvs/2006-11/008738.html
(I didn't dare touch the comment's spelling though...)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hi Hans,
In general, I've held off fixing bugs in 0.39 for fear of introducing new problems, especially since you've been working for so long to get Pd extended out. But this one is special since it's a security leak, so I'm inclined to fix it. If past experience is any guide, I'll make a mistake in a CVS commit and wreak havoc that will take days to clear up. Well, maybe not, who knows.
I'm hoping it will prove easy enough to plug 0.40 into the extended release mechanism that for non-security bug fixes, it will suffice for me to fix them in 0.40 and wait for the march of time to propagate the fix. For instance, once I find the open-GOP-close-patch bug, I can fix that both in 0.40 and "latest" but leave 0.39 alone.
Unless there's reason not to, I'll take the single offending 'e' character out of 0.39, "tag" it 0.39-3, and commit... ?
cheers Miller
On Sat, Jul 14, 2007 at 12:33:25PM -0400, Hans-Christoph Steiner wrote:
On Jul 13, 2007, at 3:36 PM, Mathieu Bouchard wrote:
On Thu, 12 Jul 2007, Hans-Christoph Steiner wrote:
This is only possible if you are running Pd as root, which is
general is not a good idea. If Pd is running as a different user,
then you wouldn't be able to gain root access.We are *only* talking about setuid (chmod +s) and not starting pd
from a root login.If pd is running as user "eighthave" but with setuid "root", pd is
dropping priviledges to be effectively just "eighthave", but does
it the wrong way, causing it to be able to regain effective "root"
later.I reported this bug last november:
http://lists.puredata.info/pipermail/pd-dev/2006-11/007910.html
I have fixed that bug in devel_0_39 on 2006.11.23.
Sorry, I didn't see the part that it was just related to setuid.
It would be very nice to have this bug fix as a patch in the tracker
so that it can be included in pd-vanilla and pd-extended..hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada
Access to computers should be unlimited and total. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oh, is this already fixed in more recent versions? I don't need to
include in this release.
.hc
On Jul 14, 2007, at 1:49 PM, Miller Puckette wrote:
Hi Hans,
In general, I've held off fixing bugs in 0.39 for fear of introducing new problems, especially since you've been working for so long to get Pd extended out. But this one is special since it's a security leak, so I'm inclined to fix it. If past experience is any guide, I'll make a mistake in a CVS commit and wreak havoc that will take days to clear up. Well, maybe not, who knows.
I'm hoping it will prove easy enough to plug 0.40 into the extended release mechanism that for non-security bug fixes, it will suffice for me to fix them in 0.40 and wait for the march of time to propagate the fix. For instance, once I find the open-GOP-close-patch bug, I can fix that both in 0.40 and "latest" but leave 0.39 alone.
Unless there's reason not to, I'll take the single offending 'e'
character out of 0.39, "tag" it 0.39-3, and commit... ?cheers Miller
On Sat, Jul 14, 2007 at 12:33:25PM -0400, Hans-Christoph Steiner
wrote:On Jul 13, 2007, at 3:36 PM, Mathieu Bouchard wrote:
On Thu, 12 Jul 2007, Hans-Christoph Steiner wrote:
This is only possible if you are running Pd as root, which is general is not a good idea. If Pd is running as a different user, then you wouldn't be able to gain root access.
We are *only* talking about setuid (chmod +s) and not starting pd from a root login.
If pd is running as user "eighthave" but with setuid "root", pd is dropping priviledges to be effectively just "eighthave", but does it the wrong way, causing it to be able to regain effective "root" later.
I reported this bug last november:
http://lists.puredata.info/pipermail/pd-dev/2006-11/007910.html
I have fixed that bug in devel_0_39 on 2006.11.23.
Sorry, I didn't see the part that it was just related to setuid.
It would be very nice to have this bug fix as a patch in the tracker so that it can be included in pd-vanilla and pd-extended.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada
Access to computers should be unlimited and total. - the hacker
ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Sat, 14 Jul 2007, Hans-Christoph Steiner wrote:
Oh, is this already fixed in more recent versions? I don't need to include in this release.
What Miller is saying is that he intends to plug the hole in 0.40, and contemplates whether to also release a new 0.39. There is currently no Miller release that does it. You can see that by looking at Miller's home page. It lists which versions there are. 0.40 is still 0.40-2; 0.39 is still 0.39-2.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Thomas Jeppesen