Kontena Lens needs access to few personal directories because it has to read kubeconfig and related cloud provider configs (mainly for credentials):
Manual connection is ok for now because we notify user if permission is denied (with instructions how to make connection).
+1 from me, to allow-installation with personal-files. But as you said, it makes sense to require manual connection (i.e. no auto-connect), particularly because the application doesn’t own those directories and it’s fair and reasonable to ask the user for permission to look at potentially sensitive files which might contain secrets.
This is currently blocking our release pipeline. Anything I can do to speed up the process?
Hi there,
There’s a standard 7-day waiting period to gather comments from reviewers before this is granted (see Process for aliases, auto-connections and tracks, requesting personal-files is not explicitly mentioned but de facto the same process is applied to this kind of request).
Other than my +1, at least another positive vote from another reviewer is also required.
One question btw - is it OK to have only read permissions to the required directories? (My +1 holds if that’s the case).
Yes, we request only read permissions.
Who should I ping to get more votes? 
Given the broad range of personal-file access being requested I think it is sensible that they are not auto-connected. @roadmr Is it possible to allow a personal-file interface and have it be manually connected only? If so, I am 
on this request.
+1 from me, given the reasonable nature of the request, catering for manual connection.
I think it’s possible; like other interfaces, we can specify separately allow-installation (without this, snapd will simply refuse to install the snap) and allow-auto-connection (as noted in my +1).
@jakolehm can you please outline why access to $HOME/.config is required? This provides access to the configuration for many other applications which the user has installed - can this instead be changed to a more specific location?
Also the I notice in an older version of the snap, you used the name kube-config for this instance of personal-files - however this is not very descriptive - since this not only provides access to $HOME/.kube but also to $HOME/.aws and $HOME/.azure etc.
Instead this should be broken into a few separate instances of personal-files which each convey to the user who is connecting them what exactly is being granted. So better would be something like a name of dot-aws-config-credentials for the $HOME/.aws access and something similar for $HOME/.azure.
Cloud provider configs (except aws & azure) are usually located under that path. Without $HOME/.config we need to list all cloud provider paths (idk how many kubernetes providers there are)… or we should request classic confinement.
The problem is that kubeconfig files can execute arbitrary binary with arbitrary cloud credentials to acquire authentication token/certificates. If kontena-lens cannot access those then it does not work at all from user perspective.
@jakolehm Does kontena-lens read these $HOME/.config/.. files directly? If so I would assume then they could be enumerated - if not can you please explain with an example which cloud provider’s config is located under $HOME/.config/ and how this is read?
@alexmurray kontena-lens does not read them directly, it gets kubeconfig file where user has configured an authentication mechanism. This config might execute gcloud cli (Google), doctl cli (Digitalocean) or any other binary which reads the actual cloud provider config. Both gcloud and doctl have config files under $HOME/.config/. It’s really problematic for snap “sandbox”… maybe kontena-lens should actually use “classic” confinement because we really can’t guess all the paths where these cloud provider configs are located?
Does kontena-lens ship the gcloud / doctl binaries? If not then I think that kontena-lens would have to use classic confinement as otherwise it will not be able to execute these binaries from the host system anyway. So this is likely to be a bigger problem than just whether it has permission to read the config files.
kontena-lens does not ship those binaries. Should I open a new request for classic confinement or change the title of this one?
At this point it might make sense to create a new request so as not to confuse things.
Opened a new request: Classic confinement for kontena-lens
