Request for personal-files confinement for k9s + Popeye


The snap is allowed to write to ~/snap/k9s/<revision>/* (including .kube) by default and the personal-files interface grants additional access to ~/.kube. If you can’t get your application to prefer one over the other via configuration or code change, simply create a symlink from ~/snap/k9s/<revision>/.kube to ~/.kube. You can create a small wrapper script or adjust your program to do something like:

myid=$(id -u)
myid_home=$(getent passwd $myid | cut -d : -f 6)
if [ ! -e "$snap_home ]; then
    ln -sf "$myid_home" "$snap_home"

In this manner, whether your application uses getpwent or $HOME, it should work.


@jdstrand Thank you for your input! Still seems less than ideal as the home is now a moving target on each release drop as the symlink will need to change. You did not answer my question regarding classic confinement. My understanding is all these problems will go away if k9s and popeye where to use it. Is this correct? And if so how can I proceed with the request?

Thank you!


This is handled by snapd. The script snippet I gave itself isn’t hardcoding any revisions so you should be ok there too. Also keep in mind that there is a current symlink down in ~/snap/k9s/current if you need it for some reason.


Since there are no restrictions put on your snap with classic confinement, you will not have any access problems. However, use of classic confinement is restricted and usually not needed. Access to dot files like we’ve been discussing is not a reason for classic confinement since either the snap can be adapted to work within the system or personal-files can be used (which is also restricted). This topic is discussing the suitability of certain uses of personal-files.

For your previous questions, SNAP_USER_DATA is versioned by snapd copies forward the data. If that doesn’t meet your use case, SNAP_USER_COMMON is not versioned and you can always choose to use that to store your artifacts. As for kubectl, you would need to ship that as part of your snap (which you would want to do anyway since there is no guarantee this will be available on the host even if you were using classic).


@jdstrand. Thank you for your reply and comments! I am still very confused. Most K9s user will most likely have kubectl either installed as snap or from the releases on their systems and most likely in their $PATH. K9s shells out to kubectl for some commands. I have installed kubectl via a snap. The user has a PATH env variable set that correctly contains /snap/bin. On the terminal which kubectl yields installed and available. This snap uses classic confinement and no extra configuration is necessary as it does find the .kubeconfig in the user’s home dir… Yet, If I run K9s and try to shell out to run a kubectl command I get kubectl is not in the PATH? So why is this failing? Sorry to be obtus here but it seems I am missing an important piece of information or I am completely missing it. I am now able to launch K9s by specifying where to find the kubeconfig but now anything I am trying to persist or launch is a total dud. Thank you for your response!