Request for home, removable-media and personal-files interfaces (was: Classic confinement for wksctl)

#1

Dear @reviewers, I would like to request classic confinement for the wksctl (https://github.com/weaveworks/wksctl) snap.

Some of its commands (e.g. wksctl apply) need to read local configuration files that are being passed by users via command line args. Ideally, enabling access to only those specified files would work fine, but as the paths are dynamic, my understanding is that the only way to make it work is by giving a broad file read-access to the snap.

An alternative I was considering is strict confinement with home / personal-files interfaces enabled, but I don’t know if that would be any better if the scope was set to the root anyway.

Thank you in advance!

1 Like
#2

References:

#3

Can you describe typical workflows that cannot be accommodated with strict mode, home and removeable-media?

#4

Can you describe typical workflows that cannot be accommodated with strict mode, home and removeable-media?

Sure @jdstrand, I’ll quote https://github.com/mflendrich here as he’s one of the main contributors to wksctl:

This is a tool that accesses a file provided by the user. It sounds like bad UX if the user was forced to have the file stored under $HOME. They could e.g. have checked the repo out to /tmp.

Indeed, if a user would try to go through any of our guides (e.g. the one I posted above as Flow example) by checking out the repo to their /tmp, wksctl would fail with only the permissions you listed.

The configuration files in question actually describe the Kubernetes cluster to be set up by wksctl, so at least in some cases, they are quite likely not to be living in any of the user home directories.

To get a better feeling of what the configuration files typically look like, please take a look at:

I hope this explains it - please feel free to ask more questions if you need more information!

#5

From my reading of wksctl I think strict confinement with the home and removable-media interface should be sufficient. So :-1: for classic confinement for me.

#6

Cloning to /tmp always feels like a strange thing to do, personally. I appreciate some might use this workflow as it results in files disappearing after some while, but I have a (possibly somewhat irrational dislike of it). This could be worked around by simply changing the docs to ~/tmp and thus cloning to a non-hidden directory in the directory allowed by the home interface.

#7

@filipbarl I also tend to agree that home and removable-media should be sufficient based on my understanding of wksctl - if this is not sufficient, can you please explain in more detail specific use-cases which can not be easily supported?

#8

@filipbarl - FYI - this request is still waiting on your response to the above questions.

#9

@filipbarl - this request cannot proceed until you provide the requested feedback.

#10

@jdstrand @popey @Wimpress @alexmurray - thank you all for your patience and for taking a look at my request!

It seems that you guys have a strong preference for strict confinement here, so I’ll go with that + home and removable-media interfaces for now and see how it resonates with our users :+1:

#11

Oh, I forgot that wksctl will definitely need to be able to write a kubeconfig file into its config dir $HOME/.wks (see step 5 here), so I’d also request access to the kube-config plug as a part of personal-files interface:

plugs:	
  kube-config:	
    interface: personal-files	
    write:	
    - $HOME/.wks

I’ll update the title to reflect that.

Edit: I pushed an updated snapcraft.yaml that’s waiting for your approval.

#12

I do not understand why the actual $HOME/.wks is required in this case. Is it possible to just use the snap specific $HOME of ~/snap/<snap-name>/<revision> rather than the real $HOME for this (in which case this path would become ~/snap/wksctl/current/.wks or similar). Can you please explain?

#13

Thanks for your reply @alexmurray!

So the way I read your proposal, there’d be two different compromises to make here from our side:

  1. Switching to snap $HOME in our code / scripts
  2. Telling our users to use a different kubeconfig path (e.g. step 6 here)

While I think 1. would not be a problem, I wouldn’t like to see us doing 2. for a couple of reasons:

  • Storing kubeconfig in a wksctl subdir might seem confusing as wksctl is just a tool via which WKS Kubernetes configuration happens to be created and there is no sense I’d say in which those kubeconfigs belong to or are owned by wksctl
  • The kubeconfig file would have a different path depending on how the users would install wksctl, so we’d likely have to treat snap installs separately in our docs
  • Other tools might want to use kubeconfigs created this way and that would be made much more difficult if they were not stored somewhere at a more global level

Does that answer your question?

p.s. I discussed this with @dholbach and the use cases / permission requests for wksctl are somewhat similar to the ones for fluxctl (see Fluxctl personal-files [Was: Fluxctl snap wants to be classic]).

#14

As per The personal-files interface, the personal-files interface is “typically used to provide read-only access to top-level hidden data directories within a user’s home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory.”

While wksctl is the clear owner of ~/.wks, you are requesting write access rather than read. What sort of compatibility guarantees does wksctl provide when wksctl provided as a snap and wksctl provided as something else are both installed on the system and both writing to ~/.wks? Will the snap break the other install or vice versa? If not, how is this achieved?

Also, while ~/.wks contains your kubeconfig, in terms of clarity for users, your snapcraft.yaml should be updated to use this instead:

plugs:
  dot-wks:
    interface: personal-files
    write:
    - $HOME/.wks
#15

@filipbarl - this request cannot proceed without the requested information.

#16

@filipbarl - as @jdstrand commented above, this request can not proceed without additional information from you - this will be removed from our internal review queue if we do not get a response within the next week. We can re-add this back to our queue if and when you get a chance to respond.