Hi Gianfranco, It appears that GTK+ has disallowed use of its APIs running setuid or setgid similarly to Apple's restrictions. So the two choices are: [1] add all users who can run BOINC Manager to the boinc group, or [2] create a helper application for Linux similar to switcher on the Mac. You will see in CMainDocument::WorkShowGraphics() in clientgui/MainDocument.cpp that the Mac uses switcher to run graphics applications this way. But the Mac's switcher (client/switcher.cpp) expects project executables to run as user and group boinc_project, and the switcher for Linux would need to set user and group boinc, so it would be slightly different. In addition, we would need to add code in CMainDocument::WorkShowGraphics() to launch the Linux switcher under Linux.
Since you have demonstrated that method [1] works, that is what I would recommend using. Cheers, --Charlie On Jul 12, 2014, at 4:11 AM, Gianfranco Costamagna wrote: > Hi Charlie, > > I appreciate a lot this idea, unfortunately seems not working at this moment > > locutus@Unimatrix01:/usr/bin $ sudo chown locutus:boinc boincmgr > locutus@Unimatrix01:/usr/bin $ sudo chmod g+s boincmgr > locutus@Unimatrix01:/usr/bin $ ll boincmgr > -rwxr-sr-x 1 locutus boinc 3199752 lug 7 09:25 boincmgr* > locutus@Unimatrix01:/usr/bin $ cd /var/lib/boinc-client/ > locutus@Unimatrix01:/var/lib/boinc-client $ boincmgr > > (process:28938): 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.html > > Refusing to initialize GTK+. > Segmentation fault (core dumped) > > > > Should boinc be patched? > > thanks a lot, > > > > Gianfranco > > > > > >> Il Sabato 12 Luglio 2014 12:44, Charlie Fenton <[email protected]> >> ha scritto: >>> On Jul 12, 2014, at 2:46 AM, Gianfranco Costamagna wrote: >>> How can we fix this? I don't think there is an easy way to run boincmgr >> with user boinc from the normal user, or not? >>> >>> should all the users be added to the boinc group? >>> >>> I added myself to the boinc group and everything works as expected now >> >> The Mac implementation is more complex than what is usually done on Linux >> and >> uses 2 custom users and groups (boinc_master and boinc_project), but I >> suggest >> taking a look at <http://boinc.berkeley.edu/sandbox.php> and >> <http://boinc.berkeley.edu/trac/wiki/SandboxUser> to get an idea of what >> we do on the Mac, using the UNIX permissions system (since Mac OS X is built >> on >> top of BSD UNIX.) >> >> On the Mac, two helper applications, switcher and setprojectgrp, allow the >> client to launch applications as a different user or group than the client. >> But >> that is probably far more complex than what is needed to solve this problem >> on >> Linux. >> >> I think the easiest solution on Linux would be to make BOINC Manager run >> setgid >> boinc, with permissions: >> -r-x--S--- some_user boinc >> where some_user can be any user. The Mac version originally worked this >> way, >> but security changes by Apple prevented using certain APIs from an >> application >> running setgid, so we then were forced to remove the setgid permission and >> instead we now add to the boinc_master group all users who are authorized to >> run >> BOINC Manager. >> >> So adding all users to the boinc group is another solution which has already >> been proven on the Mac. But I think the setgid approach is easier. >> >> Cheers, >> --Charlie >> >> On Jul 12, 2014, at 2:46 AM, Gianfranco Costamagna wrote: >>> Hi Eric and all, >>> >>> >>>> Il Sabato 12 Luglio 2014 0:10, Eric J Korpela >> <[email protected]> ha scritto: >>> >>>> >>>> On Fri, Jul 11, 2014 at 2:44 PM, Gianfranco Costamagna >> <[email protected]> wrote: >>>> >>>> Hi Eric, thanks! >>>>> >>>>> >>>>> ok, do you know then where in the code is done the write, and do >> you have any answer for the second issue? >>>>> >>>>> (shouldn't be *boinc* api writing it?) >>>>> >>>> >>>> >>>> The BOINC API creates the file and sets up the mapping. The >> application and graphics_app map the contents to variables that are directly >> read and written. The file should be read-write for the BOINC user and >> group >> and read only for others. >>>> >>> >>> And it is! The problem is: >>> boinc process runs as "boinc:boinc", the manager is run by the >> user who opens it. >>> The graphic app is then spawn by the user who is running boincmgr, than the >> app wont open because of the problem you describe >>> >>> How can we fix this? I don't think there is an easy way to run boincmgr >> with user boinc from the normal user, or not? >>> >>> >>> >>> should all the users be added to the boinc group? >>> >>> >>> I added myself to the boinc group and everything works as expected now >>> >>>> >>>>> >>>>> seti@home beta, official graphic app >>>>>> root@Unimatrix01:/var/lib/boinc-client/slots/1# ldd >> ../../projects/setiweb.ssl.berkeley.edu_beta/setigraphics_7.01_x86_64-pc-linux-gnu >>>>> [snip] >>>>> >>>>>> libjpeg.so.62 => not found >>>>>> libssl.so.10 => not found >>>>>> libcrypto.so.10 => not found >>>>> [snip] >>>>> >>>> >>>> >>>> The problem on linux (at least the last time I built SETI@home for >> distrubution) was that the graphics_app needed libraries that were not >> available >> statically (OpenGL and X11 primarily, and those libraries needed dynamic >> load >> versions of libjpeg/ssl/crypto). If you went in with a debugger you'd >> probably find a static version of libjpeg in the executable as well. With a >> lot >> of work somebody could make a version that manually demand loads OpenGL and >> X11 >> (and associated libraries), but we didn't think it was worth the effort. >> If you can make a static version, we'd gladly distribute it. >>> >>> >>> >>> Yes, this is tricky to achieve. >>> What about shipping them and tweak LD_LIBRARY_PATH to point at them? boinc >> already does something similar... >>> >>> >>> thanks for the full explanation, >>> have a nice weekend, >>> Gianfranco >>>> >>>> >>>> >>>> >>>>> Can anybody please release the official graphic client with static >> libraries linked? thanks >>>>> >>>>> >>>>> many thanks, >>>>> Gianfranco >>>>> >>>>> >>>>> >>>>> >>>>> Il Venerdì 11 Luglio 2014 19:54, Eric J Korpela >> <[email protected]> ha scritto: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> boinc_setiathome_* is the shared memory file that the app uses >> to communicate with the graphics app. * is the BOINC slot that the app is >> running in. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 11, 2014 at 4:35 AM, Gianfranco Costamagna >> <[email protected]> wrote: >>>>>> >>>>>> Hi again, >>>>>>> while I was working on that crash (BTW the problem is that >> my user have no permission to write "boinc_setiathome_0" file, do >> anybody know why it should write that file? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I found another interesting crash in s@h beta >>>>>>> >>>>>>> >>>>>>> >> ../../projects/setiweb.ssl.berkeley.edu_beta/setigraphics_7.01_x86_64-pc-linux-gnu >>>>>>> >> ./../projects/setiweb.ssl.berkeley.edu_beta/setigraphics_7.01_x86_64-pc-linux-gnu: >> >> error while loading shared libraries: libjpeg.so.62: cannot open shared >> object >> file: No such file or directory >>>>>>> root@Unimatrix01:/var/lib/boinc-client/slots/1# ldd >> ../../projects/setiweb.ssl.berkeley.edu_beta/setigraphics_7.01_x86_64-pc-linux-gnu >>>>>>> linux-vdso.so.1 => (0x00007fffae927000) >>>>>>> libglut.so.3 => >> /usr/lib/x86_64-linux-gnu/libglut.so.3 (0x00007f772478b000) >>>>>>> libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 >> (0x00007f772457b000) >>>>>>> libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 >> (0x00007f772430c000) >>>>>>> libGL.so.1 => /usr/lib/nvidia-331-updates/libGL.so.1 >> (0x00007f7723fd9000) >>>>>>> libjpeg.so.62 => not found >>>>>>> libssl.so.10 => not found >>>>>>> libcrypto.so.10 => not found >>>>>>> libstdc++.so.6 => >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7723cd4000) >>>>>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 >> (0x00007f77239cd000) >>>>>>> libpthread.so.0 => >> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f77237af000) >>>>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 >> (0x00007f77233e9000) >>>>>>> libX11.so.6 => >>>>> /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f77230b3000) >>>>>>> libXxf86vm.so.1 => >> /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f7722ead000) >>>>>>> libXext.so.6 => >> /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f7722c9b000) >>>>>>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 >> (0x00007f7722a84000) >>>>>>> libnvidia-tls.so.331.38 => >> /usr/lib/nvidia-331-updates/tls/libnvidia-tls.so.331.38 (0x00007f7722881000) >>>>>>> libnvidia-glcore.so.331.38 => >> /usr/lib/nvidia-331-updates/libnvidia-glcore.so.331.38 (0x00007f7720073000) >>>>>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 >> (0x00007f771fe6e000) >>>>>>> /lib64/ld-linux-x86-64.so.2 (0x00007f7724a02000) >>>>>>> libxcb.so.1 >>>>> => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f771fc4f000) >>>>>>> libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 >> (0x00007f771fa4a000) >>>>>>> libXdmcp.so.6 => >> /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f771f844000) >>>>>>> >>>>>>> >>>>>>> Can anybody please release the official graphic client with >> static libraries linked? thanks >>>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Gianfranco >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Il Mercoledì 9 Luglio 2014 18:08, Gianfranco Costamagna >> <[email protected]> ha scritto: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ldd setiathome_graphics >>>>>>>> linux-vdso.so.1 => (0x00007fff3cdfe000) >>>>>>>> libboinc_graphics2.so.7 => >> /usr/lib/libboinc_graphics2.so.7 (0x00007fb462f47000) >>>>>>>> libglut.so.3 => >> /usr/lib/x86_64-linux-gnu/libglut.so.3 (0x00007fb462cfd000) >>>>>>>> libGLU.so.1 => >> /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007fb462a8e000) >>>>>>>> libGL.so.1 => >> /usr/lib/nvidia-331-updates/libGL.so.1 (0x00007fb46275b000) >>>>>>>> libboinc_api.so.7 => /usr/lib/libboinc_api.so.7 >>>>> (0x00007fb46253b000) >>>>>>>> >>>>> libboinc.so.7 => /usr/lib/libboinc.so.7 (0x00007fb4622c3000) >>>>>>>> libstdc++.so.6 => >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb461fbf000) >>>>>>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 >> (0x00007fb461cb9000) >>>>>>>> libgcc_s.so.1 => >> /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb461aa2000) >>>>>>>> libpthread.so.0 => >> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb461884000) >>>>>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 >> (0x00007fb4614be000) >>>>>>>> libjpeg.so.8 => >> /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007fb461268000) >>>>>>>> libX11.so.6 => >> /usr/lib/x86_64-linux-gnu/libX11.so.6 >>>>> (0x00007fb460f33000) >>>>>>>> libXi.so.6 => >>>>> /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fb460d23000) >>>>>>>> libXxf86vm.so.1 => >> /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fb460b1c000) >>>>>>>> libnvidia-tls.so.331.38 => >> /usr/lib/nvidia-331-updates/tls/libnvidia-tls.so.331.38 (0x00007fb460919000) >>>>>>>> libnvidia-glcore.so.331.38 => >> /usr/lib/nvidia-331-updates/libnvidia-glcore.so.331.38 (0x00007fb45e10b000) >>>>>>>> libXext.so.6 => >> /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fb45def8000) >>>>>>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 >> (0x00007fb45dcf4000) >>>>>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb4633f4000) >>>>>>>> libxcb.so.1 => >>>>> /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fb45dad4000) >>>>>>>> libXau.so.6 >>>>> => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fb45d8d0000) >>>>>>>> libXdmcp.so.6 => >> /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fb45d6c9000) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> >>>>>>>> Gianfranco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Il Mercoledì 9 Luglio 2014 17:53, Eric J Korpela >> <[email protected]> ha scritto: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> We ship a graphics app binary with SETI@home, but I >> think it only works on Red Hat derivatives. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jul 9, 2014 at 8:46 AM, Gianfranco >> Costamagna <[email protected]> wrote: >>>>>>>>> >>>>>>>>> There is absolutely no code that makes difference >> from linux to others in graphic code (as far as I can see), and I see >> graphics >> uses gl, so I presume it should work on every gl-compatible platform (and I >> remember it used to work until a while ago, but I might be wrong) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> anyway, when we firstly introduced the >> boinc-app-graphics client for linux it used to work I presume. >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Gianfranco >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Il Mercoledě 9 Luglio 2014 17:33, Jord van der >> Elst <[email protected]> ha scritto: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Does Seti have a graphics application then >> for Linux? I thought they >>>>>>>>>>> only had one for Mac OS X and Windows. >>>>>>>>>>> >>>>>>>>>>> -- Jord van der Elst. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Jul 9, 2014 at 5:26 PM, Gianfranco >> Costamagna >>>>>>>>>>> <[email protected]> >> wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> sorry for posting on boinc_dev, >>>>>>>>>>>> please point me to the correct location >> if there is one for seti project. >>>>>>>>>>>> >>>>>>>>>>>> The problem is simple: opening >> "show graphics" makes seti@home crash on debian and ubuntu. >>>>>>>>>>>> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753763 >>>>>>>>>>>> >>>>>>>>>>>> How can we proceed? Should we just >> disable seti graphics for our debian client? the official client doesn't >> have graphics enabled, >>>>>>>>>>>> so I cannot reproduce the bug with the >> official one. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> thanks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gianfranco >>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>> boinc_dev mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>>>>>>>>>> To unsubscribe, visit the above URL and >>>>>>>>>>>> (near bottom of page) enter your email >> address. >> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> boinc_dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>>>>>>>> To unsubscribe, visit the above URL and >>>>>>>>>> (near bottom of page) enter your email address. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> boinc_dev mailing list >>> [email protected] >>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>> To unsubscribe, visit the above URL and >>> (near bottom of page) enter your email address. >>> >> > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
