Client: Files inside private shares are owned by user:root, which means VPN keys and the like can't be used by network-manager

[k2trf]

I'm on an Ubuntu system, with uname -a producing:
Linux desktop 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I've moved over my keys (VPN, PGP, SSH, etc.) to a private folder, but I can't control the permissions of them -- they're all forcibly stuck at k2trf:root 0700! This means they can't be used by anything else not running as me, like if I wanted the system to be able to read the cert file for my VPN.

I can't alter the permissions in any way -- they just rebound back to this value, which is very unhelpful. I get the idea as a default, and I do like it, but why on earth can users not change it after the fact? Under a normal circumstance, I suppose the answer could be to run the program/application as said user, but I can't reasonably do that for network-manager, which runs as root at system start (/usr/sbin/NetworkManager --no-daemon).

Is this a bug, or just bad design? Because if there's no way around this, I cannot use keybase to store my various keys and certs, which is really what I saw in keybase -- my certs under my control, but still encrypted and syncing (without a cloud server).

For reference, I know its a permission issue thanks to /var/log/syslog printing:
Aug 12 13:58:24 desktop nm-openvpn[5956]: Options error: --ca fails with '/keybase/private/k2trf/[PATH TO FILE].crt': Permission denied Aug 12 13:58:24 desktop nm-openvpn[5956]: Options error: Please correct these errors. Aug 12 13:58:24 desktop nm-openvpn[5956]: Use --help for more information.

Following the permission error, it was obvious when I saw
-rwx------ 1 k2trf root 1684 May 24 23:25 [FILE].crt

I can modify the user permissions, but nothing else. Literally, all I need is to give the group (root) read permissions, and I'd have my userspace working again; I just can't get the permissions to change and stick.

[strib]

This is intended, and we don't consider it a bad design. In fact, we don't want any user other than the user logged into keybase to see your files, including root. If we allowed that, then for example the OS could spider and index your private data, potentially sharing that info in the clear to other systems.

As you found, KBFS ignores user permissions changes. Besides the above, the files need to work the same way across multiple devices and OSes, and assigning permissions based on device-local UIDs doesn't make sense.

Sorry if this causes inconvenience for your desired use, but we think it's important. One way around this is to make another Keybase account for root on your devices, and store the files in a shared folder between your normal account and this root account. Then you'd run a second Keybase daemon on all your devices as root, logged into this second account. (You'd need to hack our scripts a bit to mount KBFS at some other location for root, say /keybase.root.)

[k2trf]

Like I said, I understand that being the default nature, but not allowing people to specify ownership is like your landlord giving you one key to start with (the default), and forbidding you from making any copies for roommates, family, etc. The concept works until you forbid permission changes from the user, and that means I'll have to forgo keybase as a secure and reliable method of storing this kind of data, which is unfortunate because it is what needs security moreso than anything else.

I may investigate the possibility of keeping a root folder, but you would need to have some documentations for the "hacks" you're describing. At the very least, I ask this policy be re-discussed for private shares -- public shares shouldn't need permissions changed since you can add users to the share instead. Private shares inherently can't be on any device/computer you put it on, however, and what I'm faced with now (just setting up some sort of automated sftp protocol to fetch the certificates/keys) is no better than if private shares were allowed to have permissions changed. Even just the group permissions, while retaining the lock for world perms should work fine for such use case scenarios.

[ernstae]

I've found this cumbersome, as on my linux setups, I want to keep the certificates and keys private, and only accessible to me. My initial thought was, "haha.. use kbfs" to store those. But alas, network manager cannot access the files, and so it looks like I'll have to store them locally in my home directory.

Is there any chance that you could offer a mount option in the advanced configuration of the keybase client that would allow user-manipulated file permissions (a la POSIX)? Then, users could have the choice and option to enable that behavior? In this case, I'd just be wanting to grant read access to a group, and executing a chgrp on the file.

This is obviously not a deal-breaker, but when you use multiple computers, it's better to have the files on one encrypted and shared filesystem that requires logging on to... than multiple copies scattered over multiple computers.