Hi Gianfranco, I am not really familiar with how things are usually done in the Linux world, since I am a Mac guy. You might consider creating a small script or utility that can be run when a new user is added, to add the user to the boinc group.
On the Mac, I supply a utility called AddRemoveUser (mac_installer/AddRemoveUser.cpp) and a script (mac_build/Mac_SA_Secure.sh) which are described in and available from <http://boinc.berkeley.edu/wiki/Tools_for_Mac_OS_X>, but these are much more complicated than what is needed for Linux. Cheers, --Charlie On Jul 15, 2014, at 7:47 AM, Gianfranco Costamagna wrote: > Hi again Charlie, > > >> Il Sabato 12 Luglio 2014 13:59, Charlie Fenton <[email protected]> >> ha scritto: >>> 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. >> > > yes, [1] works, but what happens if one new user is added to the system after > boinc is installed? who takes care of that? > > Many distributed installations are performed prior to user installation, I'm > wondering how many users will find an unusable graphic application... > > What is your opinion? > > thanks, > > Gianfranco > >> 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.
