No longer able to run k9s on read only file systems

[torjue]

Describe the bug Previous versions of k9s ran on read only file systems. The latest versions does not.

To Reproduce Steps to reproduce the behavior:

1. Make your config files read only
2. Start k9s, and navigate around
3. Look at error message open /home/appuser/.config/k9s/config.yml: permission denied

Expected behavior Previously K9s ran fine, but nothing was saved to the config. Quite useful in a "shared environment". Maybe not "expected behaviour", but "useful behaviour" at least.

Screenshots

[slimus]

@torjue hello! Could you please explain your case? How did you create the config file?

[torjue]

I do understand that my use case is a bit strange: We run read only k9s instances in a container inside the cluster, that is exposed with a web terminal (with some security measures).

The Dockerfile is something like this:

# Install k9s
RUN wget https://github.com/derailed/k9s/releases/download/v0.25.21/k9s_Linux_x86_64.tar.gz
RUN tar -xvf k9s_Linux_x86_64.tar.gz -C /usr/bin k9s
RUN rm -rf k9s_Linux_x86_64.tar.gz

# Create and use new user instead of root
RUN addgroup -g 1111 appgroup
RUN adduser -u 1111 appuser -s /bin/false -G appgroup -D
USER 1111:1111
WORKDIR /home/appuser

# Make it look good/better
COPY --chown=appuser:appgroup skin.yml /home/appuser/.config/k9s/

# Read only defaults, so everyone sees the same on each startup
COPY --chown=appuser:appgroup config.yml /home/appuser/.config/k9s/
RUN chmod -w /home/appuser/.config/k9s/config.yml

# Script to fetch kube context in k8s
COPY --chown=appuser:appgroup start.sh .
RUN chmod +x start.sh

CMD ["./start.sh"]

This might have just failed "silently" earlier, but now it stops us from navigating around in k9s.

My guess is that something changed around writing to the setting k9s.clusters.<cluster name>.namespace.favorites/active?

[derailed]

@torjue I am actually surprised this ever worked?? As far as I can recall K9s always persists its configuration to disk. I am not sure about the use case here?? Besides a bit of a security smell, I can see some convenience running as a shared container but you've are losing all personalization for your users.

[torjue]

We've used K9s (in read only mode) together with https://github.com/tsl0922/ttyd, as an alternative to the Kubernetes Dashboard, to provide quick insights into our clusters from a browser. Worked like a charm for about two years now. So far we haven't had the use for personalization, and actually preferred having a standarized configuration.

Security is handled with strict RBAC, OAuth proxy, private VNET, network policies and other measures, so I'm not worried there.

os.TempDir() have been mounted to a writable emptyDir volume, FYI.