bug: kbfs not working on nixos-23.11

[hugosenari]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

systemd kbfs fails to start The issue is permission denied of fusermount

dez 01 22:47:13 BO kbfsfuse[65572]: 2023/12/01 22:47:13 mount helper error: fusermount: mount failed: Operation not permitted dez 01 22:47:13 BO kbfsfuse[65572]: 2023/12/01 22:47:13 mount helper error: fusermount: mount failed: Operation not permitted dez 01 22:47:13 BO kbfsfuse[65572]: KBFS failed to FUSE mount at /home/hugosenari/keybase: fusermount: exit status 1

I can fix it by changing: config.systemd.user.services.kbfs.Service.PrivateTmp to false

But I'm not sure what it does.

Maintainer CC

@tadfisher wanted to remove PrivateTmp in #973

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.1.64, NixOS, 23.11 (Tapir), 23.11.20231201.742049b`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.15.3`
 - channels(root): `"nixos-22.11"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`
    "nixpkgs": {
      "locked": {
        "lastModified": 1701417047,
        "narHash": "sha256-c7/mCMxHgrx+shWmdUtX/vThGeymGtZH4okg/gdtRco=",
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "742049b53ce0e0d1b5aacc5836d3edf32b9cd3b3",
      }

[alevy]

I had the same issue and the problem seems to be that newer versions of kbfsfuse don't work with a a systemd PrivateTmp (at least not naively).

A simple "fix" is to add the following to your home manager config:

systemd.user.services.kbfs.Service.PrivateTmp = lib.mkForce false;

which, essentially, overrides the default home-manager systemd service configuration for kbfs.

Importantly, I have done zero due-diligence to consider whether this is a "safe" modification. This means that kbfsfuse will use a global temporary directory (it appears to be under /run/user/[YOUR_UID]/, meaning the keybase binary has access to all other globally tmp files and vice versa).

There is probably a better solution, but this at least works.

[Mange]

Thank you for this workaround! It finally works again! I've been debugging this on and off for months now and never gotten this far!

---

It was infuriating that the same command with the same environment set up worked from my terminal but not from systemd. I never noticed PrivateTmp in there.

From the systemd.exec manpage:

PrivateTmp=
   Takes a boolean argument. If true, sets up a new file system namespace for the executed processes and mounts
   private /tmp/ and /var/tmp/ directories inside it that are not shared by processes outside of the namespace.
   This is useful to secure access to temporary files of the process, but makes sharing between processes via
   /tmp/ or /var/tmp/ impossible. If true, all temporary files created by a service in these directories will
   be removed after the service is stopped. Defaults to false. It is possible to run two or more units within
   the same private /tmp/ and /var/tmp/ namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5)
   for details. [...]

So I take it that this option completely removes access to everything in /tmp for the process. Maybe fusermount needs /tmp to communicate?

Either case, I'm not worried about this at all. For most distributions of KBFS, I assume it keep access to /tmp like normal and this seems to be extra security added on top which just don't work.

[alevy]

That's right, the systemd confid recommended by keybase does not include this option.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[dmadisetti]

Should this be pushed upstream? Because the service is still dead otherwise

[alevy]

@dmadisetti this somehow doesn't seem to be the best fix, but here we go: #5655