Client: ownership/permissions of /keybase mountpoint on OS X

[hakamadare]

The ownership and permissions on the /keybase mountpoint prevent multiple user accounts on the same computer from using Keybase FS at the same time.

Replication:

1. Log in as user A.
2. Run Keybase.app.
3. Inspect permissions on /keybase:

$ ls -ld /keybase drw------- 2 user_a staff 68B Apr 12 21:38 /keybase/

1. Log in as user B.
2. Run Keybase.app.
3. Try to access files in /keybase:

$ ls /keybase/public/hakamadare ls: /keybase/public/hakamadare: Permission denied

I can imagine several potential solutions, with pros and cons:

1. Set mode g+rw on /keybase, warn the user that their files will be accessible to others on the same machine (this assumes that it's not a "real" multi-user machine, with different accounts associated with different individuals)
2. Mount and unmount the filesystem on user login/logout, and set ownership to the user that's currently logging in (i suspect that would be my preference)

[cjb]

I think, at least on Linux, this limitation's actually enforced by the kernel's FUSE layer rather than by Unix permissions -- once a user mounts /keybase, even root can't ls it, it's tied to that user.

We have some vague plans to fix this, allowing multiple users on the same machine, by implementing some kind of FUSE reflector that maps /keybase to different virtual FUSE mounts for each user depending on which user's performing the accessing.

It's not very high priority, because not many people are interested in accessing /keybase at the same time from multiple users on the same machine.

[akatrevorjay]

Why not just mount it as ~/keybase or something of the like since it's a per user mount if I may ask?

[cjb]

@akatrevorjay We've thought about it -- it's attractive to have a KBFS path be an absolute, predictable location so that it can be embedded in scripts and treated as a global URI.

[hakamadare]

@cjb i agree with the value of mounting /keybase at the filesystem root (it's like AFS all over again!).

I found a workaround, which can be performed as the second user:

1. Quit Keybase.app if running.
2. keybase launchd uninstall keybase.kbfs
3. sudo chown user_b /keybase
4. Launch Keybase.app, provide credential when prompted.
5. ...
6. profit!

$ ls -ld /keybase
drwxr-xr-x  1 root  wheel     0B Apr 13 16:23 /keybase/
$ ls /keybase/public/hakamadare
index.md     keybase.txt

[cedwardsmedia]

@cjb I'm not quite sure what the advantage would be for mounting the filesystem at the root instead of under the user's home directory. After all, from my understanding, it's generally poor practice to mess with the root of the filesystem and put your own stuff there.

After all, when writing scripts, you can easily use ~ to refer to the home directory. How often is one user going to be running a script using keybase on behalf of another user? From my own experience, I've yet to encounter this, so perhaps it is something others see a use for but I don't.

Just thought I'd throw my two cents in.

[cjb]

~ and $HOME work in _shell_ scripts, but not other types of scripts or programs. It is handled inconsistently -- many programs support it and many do not.

We'd prefer users not to have inconsistent experiences.

[akatrevorjay]

@cjb Every program works with $HOME as it's dished out from pam. Try it.

[akatrevorjay]

No offence, but every user would have a consistent experience: Go to your user folder. This is actually easier to access from GUI file managers for those that don't understand what that means, since it shows up on the left side of the list (your HOME).

[akatrevorjay]

Not to mention, what if you have more than one user on the system using keybase at once? How do you manage that mountpoint securely at that point?

[akatrevorjay]

What if the user doesn't have access to mount filesytems at /keybase due to (proper) restrictions on your destination(s) for your FUSE mounts?

[Pablohn26]

@cjb

~ and $HOME work in shell scripts, but not other types of scripts or programs. It is handled inconsistently

Is this the only reason to create keybase fs on / rather than ~/ ?

[cjb]

@Pablohn26 Yes.

(Another point -- if it were inside ~, you might argue that it should be ~/Keybase on the Mac (to follow convention) and ~/keybase on Linux, which would again break path sharing.)

[Pablohn26]

@cjb which convention do you mean? or why not ~/Keybase on Linux?

[hakamadare]

HOT DIGGITY DOG! this is fixed in 1.0.47-20180403021644+19ebebe08b!!!1!1!1111!!

caveat: i'm not quite sure it would work for the use case of multiple users logged into the same system _concurrently_, but that's not my use case

[strib]

caveat: i'm not quite sure it would work for the use case of multiple users logged into the same system concurrently, but that's not my use case

It should! I've tested it anyway. There's now a redirector mount at /keybase that sends you to the right mount based on your UID.