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:
snap_kube="$HOME/.kube"
myid=$(id -u)
myid_home=$(getent passwd $myid | cut -d : -f 6)
if [ ! -e "$snap_home ]; then
ln -sf "$myid_home" "$snap_home"
fi
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?
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!
As mentioned, for your snap to work with strict confinement, you must ship your own kubectl for your snap to use. In strict confinement, your snap is not allowed to call kubectl from the host system (since it wouldn’t be available in your snap’s runtime environment) or from other snaps (commands in /snap/bin are not available for other snaps to use due to limitations of the security sandbox (particularly around seccomp). Instead, snaps that want to expose executables to other snaps must do so via the content interface).
You are correct that a classic confinement snap would not have this limitation, however, preferring to not ship a binary in your snap is not typically a reason for classic confinement.
There seems to be a disconnect in this conversation, so I’ll try to be clear. Classic confinement provides device ownership to the snap and we limit what is allowed to use classic confinement in the public store. Classic confinement is typically only granted for snaps in the public store when the requirements of the snap are understood to not fit within snapd’s current implementation. Thus far, the requirements of k9s as they pertain to classic confinement are that it needs access to $HOME/.kube and must use kubectl. Classic confinement is therefore not warranted since we’ve granted personal-files for the former and you can ship kubectl yourself (if you prefer to use the kubectl snap, you could approach the publisher of that snap to expose a content interface that your snap could use instead).
@jdstrand Thank you so much for the clarifications on this and for taking the time to respond! So I have a few issues with this which I think warrants for a classic confinement.
Taking a kubectl dependency with the k9s snap means I have now to maintain a different release cycle to ensure an up to date deployment as kubectl revs.
This also means that the user might choose to run a different version of kubectl on their system and yet be confined to the one the ships with K9s while in K9s. This doesn’t sit right with my expectations.
K9s currently needs access to /tmp, .k9s, .kube and $PATH. Kubectl is one of the execs but we also launch a user preferred editor which per your explanation will mean, K9s needs to ship with these snaps too? An impossible requirement.
I understand the link of the k9s snap home to current, but all dots files dependency must remain stable while the K9s tool revs. Hence linking to the `current release directory would require additional symlinks for the .dotfiles.
Additionally the tmp dir is buried under the snap home and not as advertised as /tmp by the CLI. So that does mean that I would need to rewrite parts of the code whether a snap release is at play or not. Which is one of the thing I was trying to avoid in the first place.
So do I have enough here to make the case to request a classic confinement. I love Snapcraft and would love my users to experience K9s/Popeye in their best light without have to muck too much with configuration and settings ie snap install and go. I hope these make sense to your team and that your guys feel there is enough here to warrant a classic confinement.
Thank you for your time, patience and consideration!
If I’m not mistaken this can be done with xdg-open with xdg-desktop-portals from inside your snap if you plug the desktop interface. I just tested this and it works on Ubuntu, I’m unsure of the status of xdg-desktop-portals support in non-Ubuntu distros.
I don’t quite follow what you’re saying here, are you saying that the files inside the dot files will be binary incompatible between versions?
What do you need to access from /tmp that must be shared with the host’s version of /tmp?
