Additional security, as you suggest, is warranted for a client running on a remote machine, possibly headless and without human oversight. Giving local users (effectively) password-free access to view and manage the BOINC client running on their own local machine is not a great security risk - the client itself is effectively firewalled away from the rest of the operating system and local storage outside the data folder tree. My personal view is that the original developers got it about right. The Linux GUI was never given this ability, and so most Linux installations started with an empty password file - until the May update. Mac and Windows users wishing to control a remote machine have to jump through additional security processes. They took the decision - pragmatically, but as I said, debateably - that the Mac and Windows GUIs would be able to read and use the password on the local machine, without user action. The BOINC developers considered two cases: BOINC running on the local machine (localhost), and BOINC running on a remote machine ( Controlling BOINC remotely) May I point you to my analysis in - the same PR that I mentioned earlier? For me the whole concept of someone else reading the Client's private file is only added by the Linux packagers and it's another case where the convenience vs security decision goes in the wrong direction. The Manager has the ability to read the password from a file but I don't think that was meant to read the Client's password file but one provided by the user. In fact that's what I do, but I'm sure that's still not how it was intended to work. You could add authorised users to the boinc group as you suggested and then allow only those to read the password file. To make that work the password has to be secret, enforcing a password and then allowing everybody to look it up is just absurd. The user has to provide the password to prove they're authorised to control the Client. The Linux tools for ensuring that the Manager can read - and thus supply - the requisite password from gui_rpc_auth.cfg are woefully inadequate.No, the Manager should not need, and not be able, to read that file at all. This may require a Linux restart - I'm not an expert on Linux. Add the password to the command line, thusīoincmgr -password=passwordAn alternative technique is to add your user account name (since you are the one running the manager) to the 'boinc' user group, so that your copy of the manager can read boinc's files. Then, find the launcher for your BOINC manager (terminal or icon - whichever you use). Open gui_rpc_auth.cfg as a text file (may need sudo). The most reliable way of fixing this problem is to provide the new password yourself. That won't be made obvious in any messages. It depends on your distribution and installation method whether the manager can find and read the gui_rpc_auth.cfg file. Try the manager again (but don't hold your breath). After that restart, the client will be expecting those contents to be sent as the password. There is a password in use to protect the communications between the client and manager, and you have to ensure that both components are using the same, current, password.įirst - ensure that the client has been restarted since the contents of gui_rpc_auth.cfg were last altered or made readable. This is a very well known, very common, error message - and it's completely false.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |