Is it possible that your setup has the gripd python script (the file gripd or gripd.py in older versions)owned by root or has setuid bit set for gripd? The gripd pd object tries to drop setuid root privileges before running the python script by setting the effective user id to the actual userid (line 587 of gripd.c). On my setup, I have the setuid bit set for the PD executable, and it is owned by root. The gripd python script is owned by the non-root user that starts PD, and does _not_ have the setuid bit set.
Joe jsarlo@ucsd.edu
Hallo, Joseph Sarlo hat gesagt: // Joseph Sarlo wrote:
By default, GrIPD looks for gripd.py in ../gripd (relative to PD executable). To change this, send the gripd object the message "set_path <path>" where "<path>" is the path to the directory containing gripd.py. See the included README.txt file and the gripd.pd patch in gripd/examples/ for further information
Thank you for this pointer, Josef. I misunderstood the README. But now I've got another problem, when starting gripd:
Gtk-WARNING **: This process is currently running setuid or setgid. This is not a supported use of GTK+. You must create a helper program instead. For further details, see:
http://www.gtk.org/setuid.htmlRefusing to initialize GTK+.
This known behaviour of Gtk occurs because I have Pd installed suid root to gain the best performance in realtime operation. I could remove the suid bit, then gripd would run, but this could be bad for Pd performance, and I don't want to do this. Does anyone have an idea for a workaround or would this require changes to Pd itself?
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list