Using restic service with the security wrapper

Help
1

Looking at Restic - NixOS Wiki, the security wrapper seems to produce a new binary and put it in $PATH. However when I’m using services.restic.backups, all I can configure is package.

How do I connect the two things?

What I would like is to use the security patched restic binary in the restic service.

1 Like
2

When running restic as service, it is probably better to define one backup set per user and use services.restic.backups.<name>.user. The security wrapper is mainly to avoid running restic with sudo and is a middle ground between running with regular user permissions and full root access.

3

I‘m having the same problem and can’t find a solution.
Since some of my files I want to backup are owned by the root user or some other privileged user I would have to run the restic service as root which is a security risk.
The wrapper would be a great solution to this but, same as you, I don’t see any possibility of using the wrapper bin for the service.
Can someone confirm that, please? I will open a GitHub issue then.

4

I ended up hitting the same issue when switched from a user service to a system service because I wanted to back up paths in /var/lib. I’m not sure how dodgy this is, but it seems to be working just fine for me:

package = pkgs.writeTextFile {
  name = "restic-security-wrapper";
  text = ''
    #!${pkgs.runtimeShell}
    exec /run/wrappers/bin/restic "$@"
  '';
  checkPhase = ''
    ${pkgs.stdenv.shellDryRun} "$target"
  '';
  executable = true;
  destination = "/bin/restic";
};
5

There’s dedicated build helpers to make scripts, I’d use one of those. (Usually writeShellApplication since I don’t trust bash.)
https://nixos.org/manual/nixpkgs/unstable/#chap-trivial-builders

I also prefer not to hardcode paths if possible, but I don’t exactly see where the wrapper is defined… If you’ve defined the wrapper in your own config, then ${config.security.wrapperDir}/${config.security.wrappers.restic.program} should work to build the absolute path string.

Also, the NixOS restic module should be using getExe, not hardcoding /bin/restic…

6

There’s dedicated build helpers to make scripts, I’d use one of those.

The reason that I didn’t use one of those is because they use the name as the executable name, and the restic derivation is looking specifically for bin/restic, so bin/restic-wrapper would have been problematic. I guess that I could have just made the name restic, but I thought that might be confusing.

Ah but now that I look at getExe it seems like if the restic derivation were using getExe instead of bin/restic then this would work even with a different executable name? That seems like a worthwhile change. Maybe I can submit a PR for that.

Thanks for the tip for avoiding hard-coding the path. I’ll use that as well.

7

Right.​​​​​​​​​​​​​​

8

Gotcha.

That seems like the right solution, but at this point could be a breaking change. For example if someone is doing what I’ve done above then getExe will return .../bin/restic-security-wrapper since meta.mainProgram is not set. It looks like writeShellScriptBin sets meta.mainProgram but not other helpers like writeShellApplication. I doubt that this would mess many people up, but I have no way of knowing and am not sure whether to go forward with it.

9

Breaking changes are fine on unstable, but wouldn’t be ported back to stable.

(Although the build helpers probably should set it too.)

10

I’ve submitted a PR for the getExe change. I accidentally hit submit before I had gone through local testing, but I guess Hydra is doing some of that for me, and it’s a pretty straightforward change.

1 Like