I'd be happy to chown gui_rpc_auth.cfg. Where is it?
I've done file searches starting at the root directory, but I still can't find it.

How do I find gui_rpc_auth.cfg?

---

I'd be happy to chown gui_rpc_auth.cfg. Where is it?
I've done file searches starting at the root directory, but I still can't find it.

How do I find gui_rpc_auth.cfg?

/etc/boinc-client with a symlink from /var/lib/boinc[-client]

Permissions should be 664 with an owner of root and a group of boinc

I started to get this "gui_rpc_auth.cfg exists but can't be read" error after I updated my BOINC client and manager 7.16.6 installed from official Ubuntu 20.04 repos to 7.16.15 version installed from https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/boinc to check whether bug https://github.com/BOINC/boinc/issues/3715 was fixed or not.

I fixed this by

chmod 664 /etc/boinc-client/gui_rpc_auth.cfg

(thanks Bryn), but now I get another error on manager start:

Invalid RPC client password. Try reinstalling BOINC.

My manager window is completely blank, not showing my projects.

Suggestions welcome.

This is a very well known, very common, error message - and it's completely false.

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.

First - ensure that the client has been restarted since the contents of gui_rpc_auth.cfg were last altered or made readable. After that restart, the client will be expecting those contents to be sent as the password.

Try the manager again (but don't hold your breath). It depends on your distribution and installation method whether the manager can find and read the gui_rpc_auth.cfg file. That won't be made obvious in any messages.

The most reliable way of fixing this problem is to provide the new password yourself. Open gui_rpc_auth.cfg as a text file (may need sudo). Copy the contents. Then, find the launcher for your BOINC manager (terminal or icon - whichever you use). Add the password to the command line, thus

boincmgr --password=password

An 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. This may require a Linux restart - I'm not an expert on Linux.

chmod 664 /etc/boinc-client/gui_rpc_auth.cfg

Only do that if you want to effectively disable password protection, as outlined by Richard. Else set the mode to 640, maybe 660.

Invalid RPC client password. Try reinstalling BOINC.

Last time I looked at a fresh password file it was empty. You may need to set a password manually.

Last time I looked at a fresh password file it was empty. You may need to set a password manually.

You need to look again, specifically at https://github.com/BOINC/boinc/pull/3709.

Since May this year, a password has been required, and will be created (random 32-byte string) if not present. The Linux tools for ensuring that the Manager can read - and thus supply - the requisite password from gui_rpc_auth.cfg are woefully inadequate.

So, thanks for your input.

@Richard: indeed a

systemctl restart boinc-client

fixed the "Invalid RPC client password", now the manager starts with no error and I can see my projects. I didn't have to change any password.

@floyd: so you suggest to revert my chmod 664 on /etc/boinc-client/gui_rpc_auth.cfg, but if I do this I'm pretty sure I will get again the "gui_rpc_auth.cfg exists but can't be read". Also, I'm a bit lost: even if I set permissions 664, the manager was complaining about the RPC password until I restarted the client, like if the two components were not using the same credentials. So, should I understand from last Richard message that indeed my installation is still using a password and that 664 is the right permission to set on /etc/boinc-client/gui_rpc_auth.cfg?

Is there anything else I should do to ensure proper configuration after upgrading from 7.16.6 to 7.16.15?

The critical things to note are:

The client service has to be able to both READ and WRITE the file. It seems it already has this ability.
The user running the Manager has to be able to READ the file. They do not need to write to it, and for security, should not have permission to do so - else another user on the same system would be able to muck you about. This is the only part you need to preserve from your original changes.

I'm not sufficiently Linux-fluent to express that in chmod numerics, but that's the principle. The other solution to the permissions conundrum would be for the principal operator to join a group - boinc - which already has the requisite read permission.

Could a Linux expert please proof-read this analysis?

Starting from https://docs.oracle.com/cd/E86824_01/html/E54763/chmod-1.html

The Owner of gui_rpc_auth.cfg has to be able to both read and write it - but it's not executable. So 6
The Group of BOINC users has to be able to read it. So 4
Other users - it depends whether you're a member of the boinc group. If yes, you're covered above. If no, you're an 'other user' - so you need a 4.

So, 640 for members of the boinc group: 644 if you haven't done that yet.

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. The user has to provide the password to prove they're authorised to control the Client. To make that work the password has to be secret, enforcing a password and then allowing everybody to look it up is just absurd. You could add authorised users to the boinc group as you suggested and then allow only those to read the password file. In fact that's what I do, but I'm sure that's still not how it was intended to work. 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. Correct me if I'm wrong. 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.

That's a very fair debating point. May I point you to my analysis in https://github.com/BOINC/boinc/pull/3709#issuecomment-627906655 - the same PR that I mentioned earlier?

The BOINC developers considered two cases: BOINC running on the local machine (localhost), and BOINC running on a remote machine (Controlling BOINC remotely)

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. Mac and Windows users wishing to control a remote machine have to jump through additional security processes.

The Linux GUI was never given this ability, and so most Linux installations started with an empty password file - until the May update. Hence the current problems.

My personal view is that the original developers got it about right. 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. Additional security, as you suggest, is warranted for a client running on a remote machine, possibly headless and without human oversight.

If you feel that the Linux user should be required to deliberately provide a password for local control too - that's the debate - then logically the same requirement should be applied to Mac and Windows users too.

@floyd: so you suggest to revert my chmod 664 on /etc/boinc-client/gui_rpc_auth.cfg, but if I do this I'm pretty sure I will get again the "gui_rpc_auth.cfg exists but can't be read".

The message appearing or not depends on who or what issued it, but the effect is the same. You would again not be able to read the password from that file. Not without further action like adding yourself to the boinc group. The 4 at the end means read permission for everybody and as it is now you are everybody. Remember everybody else also is everybody.

Also, I'm a bit lost: even if I set permissions 664, the manager was complaining about the RPC password until I restarted the client

Are you sure that was the manager complaining, not the client and the manager only displayed the message?
Edit: Ignore that, of course the manager can't display a message from the client if it can't connect.

So, should I understand from last Richard message that indeed my installation is still using a password and that 664 is the right permission to set on /etc/boinc-client/gui_rpc_auth.cfg?

You are using a password but it is not safe. It works but you have to decide if that is good enough for you.

A little background first. I've been a BOINC user for several years now, running it on Debian GNU/Linux stable distributions (currently 10.6) from the included packages (currently 7.14.2). That's what I have experience with and I think I can talk about. But what is true for me may not be for you, possibly running later releases on other distributions. Yet not knowing better I have to assume it is.

May I point you to my analysis in https://github.com/BOINC/boinc/pull/3709#issuecomment-627906655

I've read that but am unsure about the outcome. Obviously something has been implemented but it's not clear to me what it was exactly, i.e. to what extent the suggestions have been followed.

The BOINC developers considered two cases: BOINC running on the local machine (localhost), and BOINC running on a remote machine

I don't see a difference there. The manager insists on running from /var/lib/boinc-client (that's how the distribution set it up), tries to read the password from there and uses it for local and remote connections. This behaviour is probably the only reason why I'm forced to install a client with the manager.

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.

I don't strictly reject the idea but there must be limits. If anybody and anything on the local machine has complete control over BOINC, a system designed to download and run external code, that's not acceptable. At least it needs to be restricted to users approved by the administrator.

My personal view is that the original developers got it about right. 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

You seem to make some assumptions there. First that users are real persons. And second that there's only one of them, probably you, or they're all equally reliable. Those assumptions make the decision easier but they're not necessarily true.

the client itself is effectively firewalled away from the rest of the operating system and local storage outside the data folder tree

Firewall is a very big word for what I see. Nothing keeps BOINC inside its directory and outside it's subject only to the usual file system restrictions. It can do everything any other user can do, including running malicious code, intentionally or not.
In the other direction hardly any effort is made to keep others away from BOINC. In my experience all BOINC files are world readable, including those containing sensitive information. I don't see why any BOINC data, except maybe the one file we're talking about, should be accessible from outside the boinc group. And even for the group I'd think twice.

Additional security, as you suggest, is warranted for a client running on a remote machine, possibly headless and without human oversight

All machines I can put my hands on are equally safe or unsafe, the one with the screen and keyboard is no exception. All should have some kind of access control.

If you feel that the Linux user should be required to deliberately provide a password for local control too - that's the debate - then logically the same requirement should be applied to Mac and Windows users too.

I feel there has to be some kind of access control, both for local and remote clients. My reason is not so much to differentiate between persons (that's what you usually mean when you say "user") authorised to control the client and persons not authorised, though IMO that would be a desirable side effect, but between persons and non-person users. The non-persons MUST be excluded from client control, in particular, but not limited to, the pseudo user running the science applications. If that works reliably without giving a password that's fine with me. Possibilities will be different between operating systems, also between local and remote systems, so I don't say people should be forced to enter a password every time.

On Linux the same user runs the client and the science applications. That IS a problem IMO, because one role should be as restricted as possible and the other needs full access to BOINC data. I don't see how that could be solved without a second user but that's probably not high on the priority list.

To add to the confusion, with a clean install of Ubuntu20.10 and the default offering of BOINC (7.16.11) I got the manager complaining about the password even after adding myself to the boinc group and trying the various permission changes. I then installed the Xfce desktop and after rebooting, everything worked. Next step is to roll my own on the laptop again.

I usually do a chown boinc:boinc on the two BOINC folders (/etc/boinc-client and /var/lib/boinc-client) and don't seem to have issues. For the manager I added a desktop shortcut but modify it to add --passwd xxx to its command line so it can connect. This is under Debian buster using the repo version of BOINC with the Mate desktop.

---

MarkJ

For CentOS/RHat

sudo chmod 664 /var/lib/boinc/gui_rpc_auth.cfg

Then start the service

service boinc-client start

Hi All,

Well here I am once again with another problem or issue with getting Boinc Manager along with Einstein@Home to work. I've had my Bonic Manager working great until I upgraded my Linux Ubuntu 20.04lts to Ubuntu 20.10 yesterday Now, I get the following message:

gui_rpc_auth.cfg exists but can't be read. Check the file permissions

I've purged and reinstalled several times now and no change. So how do I fix this?
Regards,
John

Add your user name to the boinc user group. It's a false message.

Stickying this thread, as it appears it's still a problem.

I've found a new (?) page, which may assist readers and save them wading through this whole thread.

Accessing BOINC on Linux

The final suggestion on that page is

exec su $USER

That only works if you want to launch BOINC Manager from the command line in terminal. If you want to use a graphical launch icon on your desktop, or a menu item created by your distribution, you'll need to reboot the machine.