Posts by floyd

1) Message boards : Projects : New project started: LODA (Message 108078)
Posted 13 May 2022 by floyd
Post:
ProtectSystem=strict
ReadWritePaths=-/var/lib/boinc -/etc/boinc-client
That configuration makes the system read-only for BOINC, with few implicit or explicit exceptions. /tmp is none of those. You could override the configuration to allow /tmp but that would have to be done for every client. Or you could make the application developers aware that they are effectively restricted to the BOINC data directory.
2) Message boards : Projects : New project started: LODA (Message 108075)
Posted 13 May 2022 by floyd
Post:
Currently in discussion on their boards because everything is failing for me and at least one other user.

confirmed to project Admin that /tmp is writeable.
systemctl cat boinc-client.service
will probably confirm the opposite.
3) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101275)
Posted 24 Oct 2020 by floyd
Post:
The client (and only the client) is designed to download external files, write them to disk, and as you say, anything is possible. High security is needed.
Not to forget the science applications, being the client's children, can do the same. As far as I know there's even applications designed to download external code, potentially not under control of the project, and execute it. Yes, anything is possible. And then there's still the potential gap between design and reality.

The manager doesn't download anything, and only writes its own configuration settings. For that to become a malicious executable, somebody would have to persuade you to download a spoof version of BOINC.
Even the genuine manager can make you do things you're not prepared for and probably wouldn't want. It allows you to open links provided by the projects which could trick you into visiting crafted sites. And it can even run external code. Recently there was an issue with Rosetta@Home where a project notice opened a YouTube video without user interaction. Unintentionally in that case but it shows what is possible.

The installer is probably the most dangerous of all, but you have to explicitly authorise it. That's why the BOINC developers have always resisted the siren voices that call for an auto-update mechanism.
On Linux there is no separate installer binary, the system-wide package management is used under control of the boinc package. I have to admit that I routinely authorise that without further checks, that's effectively pretty much auto-update. At least it has to be triggered by a known source.
4) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101273)
Posted 24 Oct 2020 by floyd
Post:
By that wording, I was meaning to refer primarily to the BOINC data folder structure, where most writing takes place.
Yes, that's the obvious place. What's not so easy to think of is the exceptions.

BOINC writes in other places too - offhand, the sticky GUI configurations in the user's home folder (hidden), the GUI lock file
Oh, just noticed your edit, so no comment necessary here.

and maybe more
Few words hiding many questions. When, where, why? Acceptable or not? What are the options? I'm not asking you to answer these questions but be aware that they need answering to make a good decision. Obviously I'm thinking of /tmp here, among possible other places.

But these are not areas where an executable file could end up.
There I disagree. I take it you mean to say those particular files you're thinking of aren't executables, but if BOINC or someone else can write at all they can write anything.
5) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101265)
Posted 24 Oct 2020 by floyd
Post:
The point is that BOINC is allowed to download and execute binaries from the projects. I don't think it's ever happened (yet!), but a project could be hacked or go rogue, and start distributing malware. That shouldn't be allowed to escape into the host operating environment.
I fully agree with you. I'm absolutely not advocating against separation, I'm only thinking about this particular systemd feature, separating a service's /tmp and /var/tmp from the rest of the system. There must be a reason behind this feature existing but I can't think of it. Does it apply here or did someone just use all available security features without noticing it affects functionality? I can't judge that. Besides, it's only a theory so far.

BOINC should be able to read system files
As far as everybody is able.

but should most definitely be blocked from writing outside its defined area
Is there a defined area or are we seeing a corner case of a possible definition?
6) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101243)
Posted 23 Oct 2020 by floyd
Post:
It may be somewhere in the systemd implementation
Right while I was typing. :-)

the permissions I could read were 777
1777 for me, where the 1 didn't allow me to easily see if it was 1777 or 1776. The latter could have been the problem but 1777 it was.

But isn't BOINC supposed to be sandboxed under systemd. Could that block out the rest of the world?
If I'm right BOINC is blocked out from the rest of the world here.
7) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101242)
Posted 23 Oct 2020 by floyd
Post:
I'm getting "#define ENOENT 2 /* No such file or directory */" - but I can see it on my machine. ??
I couldn't imagine how you could get ENOENT when trying to open /tmp/.X11-unix/ but now I have a theory. Maybe you want to verify it.

If you run BOINC as a systemd service and you have PrivateTmp=true configured or something to that effect, BOINC should have its own /tmp where /tmp/.X11-unix/ doesn't exist. If so you'd need to give the BOINC service access to the global /tmp. I'm not sure if that is advisable but can't think of any risks now. On the other hand, as shown above one often can think of something the next day.
8) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101238)
Posted 23 Oct 2020 by floyd
Post:
So, after letting my head spin round it a bit, I thought "Can we find the list of X servers any other way - like a static list?"
Look at the comment in the file you referred to, line 1809. It says BOINC already does use a static list as a fallback:
If we can't open this
    // directory, or the display_values vector is otherwise empty, then a
    // static list of guesses for open display servers is utilized instead
    // (DISPLAY values ":{0..6}") that will attempt connections to the first
    // seven open Xservers.

But I can't find that in the code.

So I made a new file - empty, two-character name, just like the old one - says it's a text file instead of a socket file, but who's counting by this stage?

Built a new client with the new location - AND IT WORKS! Now to tell git...
Tell git what? That you want to mimic what you can't read originally in some other place, where you have to set it up yourself and can't be sure it gives the same information the original would? That's an ugly workaround, no better than what the comment suggested and more complicated. Instead of re-inventing the wheel I think you'd better find a copy of the code that was apparently removed, but understand why it was.

Edit: Found it, it's https://github.com/BOINC/boinc/commit/7ff020c48781099c02c71020e2518a0bd13c65c3, also saying why the code was removed. If that is correct your idea wouldn't work better.
It's a recent change by the way. That could explain different behaviour between clients.
9) Message boards : Questions and problems : Changing BOINC Data Directory on Fedora Linux 32 (Message 101212)
Posted 22 Oct 2020 by floyd
Post:
That ls output looks good to me, except I've never seen a dot after the rwx flags before. The GNU coreutils documentation says

    Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method.

    GNU ls uses a ‘.’ character to indicate a file with a security context, but no other alternate access method.

    A file with any other combination of alternate access methods is marked with a ‘+’ character.

That sounds like it could matter but I'm guessing now. You may want to read more on "security context" and use the --context option with ls. This is terra incognita to me, I'm afraid I can't help you there.
10) Message boards : Questions and problems : gui_rpc_auth.cfg exists but can't be read. Check the File permissions. (Message 101203)
Posted 21 Oct 2020 by floyd
Post:
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.
11) Message boards : Questions and problems : gui_rpc_auth.cfg exists but can't be read. Check the File permissions. (Message 101200)
Posted 21 Oct 2020 by floyd
Post:
@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.
12) Message boards : Questions and problems : gui_rpc_auth.cfg exists but can't be read. Check the File permissions. (Message 101198)
Posted 21 Oct 2020 by floyd
Post:
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.
13) Message boards : Questions and problems : gui_rpc_auth.cfg exists but can't be read. Check the File permissions. (Message 101192)
Posted 21 Oct 2020 by floyd
Post:
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.
14) Message boards : Questions and problems : Changing BOINC Data Directory on Fedora Linux 32 (Message 101172)
Posted 20 Oct 2020 by floyd
Post:
I ran ps aux, but I don't see anything related to BOINC
So it seems BOINC is not running but still detected and thus won't start. Detection is done with a lock file, let's look at that.
ls -ld /mnt /mnt/linux-files /mnt/linux-files/boinc-data /mnt/linux-files/boinc-data/*lock*

I think minimum requirements are x permissions for the whole path as well as rw for the data directory and the file if it exists. It shouldn't though. You did not copy the data directory while boinc was running, did you?

"Probably unrelated, I guess /var/lib/boinc was boinc's home directory. I'd link /mnt/linux-files/boinc-data to /var/lib/boinc to make sure it exists." - Floyd

So, I should try making /var/lib/boinc a symlink to /mnt/linux-files/boinc-data or is it vice versa?

ln -s /mnt/linux-files/boinc-data /var/lib/boinc
so you get
/var/lib/boinc -> /mnt/linux-files/boinc-data
Just in case anything is referring to $HOME or /var/lib/boinc explicitly.
15) Message boards : Questions and problems : Changing BOINC Data Directory on Fedora Linux 32 (Message 101155)
Posted 19 Oct 2020 by floyd
Post:
Oct 18 15:49:27 ben-fedora systemd[1]: Started Berkeley Open Infrastructure Network Computing Client.
Oct 18 15:49:27 ben-fedora boinc[4267]: 18-Oct-2020 15:49:27 [---] cc_config.xml not found - using defaults
Oct 18 15:49:37 ben-fedora boinc[4267]: 18-Oct-2020 15:49:37 Another instance of BOINC is running.
Oct 18 15:49:37 ben-fedora systemd[1]: boinc-client.service: Main process exited, code=exited, status=108/n/a
Oct 18 15:49:37 ben-fedora systemd[1]: boinc-client.service: Failed with result 'exit-code'.

BOINC exited because it detected it's already running. The first question now is, is this correct? ps aux should tell you. If it is running, the next question is where it came from. Else, why was it detected incorrectly?

Probably unrelated, I guess /var/lib/boinc was boinc's home directory. I'd link /mnt/linux-files/boinc-data to /var/lib/boinc to make sure it exists.
16) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101146)
Posted 18 Oct 2020 by floyd
Post:
I'll try that xhost command later, and report back.
Tried it (with sudo). Got the response

localuser:boinc being added to access control list

That looks as expected.

still the same error message in idle_detection_debug. I'll try a reboot

xhost settings are not persistent. That's why Debian has this:

$ cat /etc/X11/Xsession.d/36x11-common_xhost-boinc 
#
# Some boinc headers needed so if some poor admin stumbles across this he knows where it came from...
#
# This file is sourced by Xsession(5), not executed.
BOINC_USER=boinc
#
# If xhost (from x11-xserver-utils) is installed, use it to give access
# to the X server to any process from the same user on the local host.
# Unlike other uses of xhost, this is safe since the kernel can check
# the actual owner of the calling process.

if type xhost >/dev/null 2>&1; then
  id -u $BOINC_USER >/dev/null 2>&1 && xhost +SI:localuser:$BOINC_USER || :
fi

Ignore the comments. Everything not explicitly mentioning BOINC has been copied from 35x11-common_xhost-local. I routinely comment out the last three lines, I prefer not to grant all the BOINC world access to my X server.

So after it didn't work for you I decided to try it myself for comparison. The initial setup was like this:
- BOINC 7.14.2 from Debian
- "Suspend when computer is in use" (SUSPEND) off
- idle_detection_debug (DEBUG) off
- "xhost +si:localuser:boinc" (XHOST) unset as mentioned above

I switched SUSPEND on and nothing happened. Set XHOST and computation was suspended. After a while, possibly the configured 3 minutes, computation resumed. Then I unset XHOST again. While typing, BOINC suspended but resumed soon after the command. All as expected so I switched SUSPEND off again.

Now comes the confusing part. I wanted to do all again with DEBUG on. Set DEBUG, set SUSPEND, and ... suspended. Without XHOST. Switched SUSPEND back and forth, suspension followed. Turned DEBUG off, still the same. Even after a reboot. I don't know what happened there, I can only imagine it was one of those little services that run in the background for my "convenience", without my knowledge, where only the gurus can tell what the hell they're doing exactly. Oh how I hate that. However, after a while and another reboot things returned to normal. But during all that I never saw any debug output. Maybe someone can make sense of that, I can't.
17) Message boards : Questions and problems : Linux Suspend when computer is in use bug. (Message 101138)
Posted 18 Oct 2020 by floyd
Post:
Debian's BOINC does "xhost +si:localuser:boinc", I suspect that's required for idle detection. Can't tell for sure, I have disabled it.
Remember there's the idle_detection_debug log flag.
18) Message boards : Questions and problems : Changing BOINC Data Directory on Fedora Linux 32 (Message 101061)
Posted 11 Oct 2020 by floyd
Post:
I think it should work like this:

1. (Optional) Suspend BOINC's network activity. Just a precaution so if anything goes wrong the effect is limited to your local machine and you can try again.

2. Stop BOINC.
sudo systemctl stop boinc-client.service

3. Copy the data directory /var/lib/boinc to the new position. Make sure to preserve ownerships, permissions and links. I can't tell you how to do this on NTFS.

4. Create an override file
sudo systemctl edit boinc-client.service
with this content
[Service]
ReadWritePaths=-/my/boinc/dir
WorkingDirectory=/my/boinc/dir
ExecStart=
ExecStart=/usr/bin/boinc --dir /my/boinc/dir

5. Reload the configuration.
sudo systemctl daemon-reload

6. Restart BOINC
sudo systemctl start boinc-client.service

7. After you have verified that all works well resume network activity.
19) Message boards : Questions and problems : Changing BOINC Data Directory on Fedora Linux 32 (Message 101053)
Posted 11 Oct 2020 by floyd
Post:
I want to move my BOINC data directory from where it was installed on Fedora 32 (through the repos) to an NTFS volume on a hard drive I have.
I'm not sure if it will work without issues on NTFS. Some other place could be easier.

I found this post by BobCat13 describing the process how to move the data directory on Linux.
That is outdated. For a start please show the output of
systemctl cat boinc-client.service
20) Message boards : Questions and problems : Move data dir on Ubuntu ? (Message 93901)
Posted 25 Nov 2019 by floyd
Post:
Disclaimer: I haven't done this myself and I'm writing this as a Debian user. Ubuntu is very similar I suppose.

On an Ubuntu 18.04 server with boinc-client 7.9.3+dfsg-5ubuntu2 installed, I do not want the boinc data dir to be on /var/lib/boinc-client but somewhere else, on another partition, say /home/boinc-client where there's far more free space.
Note /home/boinc-client.

Changing the BOINC_DIR value in /etc/default/boinc-client is not enough, even with a symlink in /var/lib to the new location.
/etc/default/boinc-client is only for the sysvinit startup script. Creating the symlink(s) is a good idea in case the path is hard-coded somewhere.

Changing the WorkingDirectory variable in /lib/systemd/system/boinc-client.service neither (yes, with systemctl daemon-reload...)
That looks like the way to go. Let's check the service file:

[Unit]
Description=Berkeley Open Infrastructure Network Computing Client
Documentation=man:boinc(1)
After=network-online.target

[Service]
ProtectHome=true
Type=simple
Nice=10
User=boinc
WorkingDirectory=/var/lib/boinc
ExecStart=/usr/bin/boinc
ExecStop=/usr/bin/boinccmd --quit
ExecReload=/usr/bin/boinccmd --read_cc_config
ExecStopPost=/bin/rm -f lockfile
IOSchedulingClass=idle

[Install]
WantedBy=multi-user.target

And now man 5 systemd.exec:

[...]
       ProtectHome=
           Takes a boolean argument or the special values "read-only" or
           "tmpfs". If true, the directories /home, /root and /run/user are
           made inaccessible and empty for processes invoked by this unit.
[...]

Hm, have you tried any other place?


Next 20

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.