Client: Linux client without root

[tromer]

How can I use the Linux client without root privileges? In particular, a tarball instead of a .deb/.rpm, and a non-root FUSE mount for kbfs?

@maxtaco mentioned it's possible, but I can't find the downloads/documentation.

[maxtaco]

Hi @tromer, to clarify, do you want to run the GUI or not?

[maxtaco]

(BTW, it's all buildable and configurable as you ask, but we haven't documented it yet...)

[tromer]

Ideally both filesystem+CLI and GUI, of course. The former would be a good start...

The client+kbfs seem to have a rather large network-facing attack surface, so I'm probably not the only user in your target audience that's reluctant to grant root privileges. Currently running them in a dedicated VM, which is rather awkward.

[strib]

KBFS+client don't run as root. You only need root to install the packages (depending on your OS) and to create the /keybase mount point. But the actual processes run as your user when you run run_keybase. We very much agree they shouldn't be run by root!

[maxtaco]

@strib I was wondering if we should supply instructions for people who don't want to run any commands as root. They'd obviously need go, node, yarn and some electron prereqs installed.

The stumbling block I hit was out to do this without trusting GitHub for source code integrity on software updates. @tromer the advantage of using the standard system installers is that we do get to sign all updates with out private key before they go out. It's TOFU, but after the first use, all subsequent updates can be signed (same on MacOS and Windows).

[strib]

Ah, got it, sorry if I misunderstood.

[maxtaco]

@strib thanks for the clarification either way

[maxtaco]

To answer my own question, we'll have to start signing a snapshot of our repo as we release. I'll talk it over with @cjb and @oconnor663 to see if that would be easy to work into our release system

[oconnor663]

We can certainly add more signed artifacts to the build, that's pretty easy. Though it might be worth admitting to ourselves: If our build is just signing the tip of a branch that it's fetched from GitHub, is that better than telling users to trust GitHub? (Hmm, maybe it's better in that GitHub would have to lie to everyone in the world to do something bad, rather than targeting a single user?)

[maxtaco]

From our internal discussion, we discussed making a kbbuildbot account, releasing a sidecarkeybase-v1.0.25.tgz.saltpack signature, and then instructing users to run:

keybase verify --signed-by kbbuildbot -d keybase-v1.0.25.tgz.saltpack -i keybase-v1.0.25.tgz`

Alternatively:

diff <(keybase fs read /keybase/public/kbbuildbot/keybase-v1.0.25.tgz.sha256) <(shasum -a 256 keybase-v1.0.25.tgz)

Alternatively, and this is probably the best bet:

keybase fs read keybase/public/kbbuildbot/keybase-v1.0.25.tgz | tar -xvz

[tromer]

Related to #2604, #4739: /keybase requires root and excludes other users; so user-local install would need $HOME/keybase.

[maxtaco]

@tromer, that /keybase is just a command-line option to the kbfs process, so easy to twiddle if you're wiling to go one level deeper than our standard install.

[oconnor663]

Also at least on Linux, we create the /keybase path and make it anyone-writable during the install. Then when you start Keybase and mount the FUSE filesystem there, I think it's the FUSE kernel module's job to enforce that only your user is allowed to access it after that. (But yes, also possible to change the mount path by invoking kbfsfuse manually. That's all the run_keybase script is doing, under the hood.)

[milouse]

For those interested in a simple way to relocate the keybase folder, I've written a little patch and explained how to use it.

[maxtaco]

I took a quick look at the patch, it looks good to me. Thanks for posting that @milouse! (Here's what I reviewed in case it changes later:)

--- run_keybase 2017-09-05 11:24:21.824977665 +0200
+++ run_keybase.new     2017-09-05 11:26:07.681249972 +0200
@@ -17,8 +17,8 @@
 if killall Keybase &> /dev/null ; then
   echo Shutting down Keybase GUI...
 fi
-if fusermount -uz /keybase &> /dev/null ; then
-  echo Unmounting /keybase...
+if fusermount -uz "$HOME/keybase" &> /dev/null ; then
+  echo "Unmounting $HOME/keybase..."
 fi
 if killall kbfsfuse &> /dev/null ; then
   echo Shutting down kbfsfuse...
@@ -45,8 +45,9 @@
 # We set the --auto-forked flag here so that updated clients that try to
 # restart this service will know to re-fork it themselves. That's all it does.
 keybase -d --log-file="$logdir/keybase.service.log" service --auto-forked &>> "$logdir/keybase.start.log" &
-echo Mounting /keybase...
-kbfsfuse -debug -log-to-file /keybase &>> "$logdir/keybase.start.log" &
+echo "Mounting $HOME/keybase..."
+[ ! -d "$HOME/keybase" ] && mkdir "$HOME/keybase"
+kbfsfuse -debug -log-to-file "$HOME/keybase" &>> "$logdir/keybase.start.log" &
 echo Launching Keybase GUI...
 /opt/keybase/Keybase &>> "$logdir/Keybase.app.log" &

[marmarek]

The stumbling block I hit was out to do this without trusting GitHub for source code integrity on software updates.

Signing release tags (at least) would be a good start. Then anyone can verify if specific version fetched is what you've pushed.

[oconnor663]

@marmarek you can find signature files over our binary packages here: https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/index.html

[marmarek]

I know, but there are no signatures of the _source_ code.

[berot3]

sooo how about a quick-guide for installing (git clone and make install to home) for keybase-cli as user? 😃

installing the dependecies should be no problem - like @maxtaco said: go, node, yarn which all do not need root right?

[oconnor663]

You can find instructions for building and running the CLI from source here: https://github.com/keybase/client/tree/master/go

[heronhaye]

There are instructions for installing without root at https://keybase.io/docs/linux-user-guide#installing-keybase-without-root-privileges.