Client: Need global options

[zander]

The keybase app supports tor by adding 2 arguments to the invocation of 'keybase'.

The problem is that after a reboot (linux with kde) the keybase background process is already running and it already started communicating with the main server over the plain internet.

Ideally I could edit the (json) config file to make sure that the arguments I need to be passed to the background instance as well as the keybase-fuse process are passed automatically without any manual interference from me.

Maybe this is already possible but the config file just isn't documented to the level that it should be, in which case I'd love to know how to make this work.

Otherwise I'd suggest a new feature to be added which is that there is some config file for command-line arguments.

[cjb]

The desktop autostart file calls a command called run_keybase -- I think you can edit that shell script to do what you need. Oh, but it'll be overwritten when you upgrade Keybase.. so I guess you're right that we can't do this easily yet.

[abeluck]

I looked everywhere for this, and finally stumbled on this issue.

I just want a package/update friendly way to add --tor-mode or --proxy to the run_keybase script.

[oconnor663]

I've deleted some comments from this thread for being not nice. Let's keep it nice folks.

@zander we're a few days away from turning on systemd integration for our background services. Once that's all turned on (or if you want to turn it on yourself now by setting KEYBASE_SYSTEMD=1 in whatever place affects your whole desktop), you should be able to edit the flags that the service is started with using something like systemctl --user edit keybase.service. (Some examples.) Please let us know if you get a chance to give that a shot.

[zander]

we're a few days away from turning on systemd integration for our background services.

Can you point to more docs on the design for this?

My first thought is that the current keybase system is per-user, you can have multiple users on the same single machine use different keybase accounts.
How is this property preserved in a system-wide service? Security to separate those users chats etc sounds rather tricky to do.

[oconnor663]

Apologies for not documenting this at all (you can find some details in another issue: https://github.com/keybase/client/issues/5355#issuecomment-342590835). In part that's because our documentation story isn't stellar in general, and in part it's because the exact details won't be stable until we've had it turned on in production long enough to be confident of them.

To your specific question, we're installing user-level services (/usr/lib/systemd/user/...), rather than system-level services, so the security situation shouldn't change much. If you look inside run_keybase, you can see our two startup paths, start_background (old) and start_systemd (new, but still off by default). In particular, in the latter we launch our services with systemctl --user.

[xkr47]

Couldn't we just change the --tor-mode to persistently save the mode to use and always use that after that in that installation? A new option --tor-mode none would then be needed to persistently disable it if one wanted to.

Alternatively we could add a new flag not to break existing usage e.g. --tor-mode-persist <mode>.

Then we wouldn't have to worry about hacky editing of startup scripts and whatnot other software that might use keybase..

[heronhaye]

@xkr47 You can change your tor mode settings with the json config file. See https://keybase.io/docs/command_line/tor.

In general, most options can be controlled by the json config file permanently without messing with run_keybase or editing systemd units. But if you need more control and you're on systemd, you can use drop-in units; they won't be overwritten on upgrade.