I’m new here and my initial experience with this community so far has been great. My release was rejected due to using the personal files interface, however this interface is required for my Snap to work because it needs to read and write to a few specific files inside the user’s home drive. A quick description of my app is that it need to watch the user’s vimrc file and update changes to that file as config which gets carried across shell sessions.
Unfortunately, theres no way to make this work without access to the personal files interface - ($HOME/.vimrc, $HOME/.vim, etc ). I made sure to limit the surface to only the files that were strictly required by my app.
Just to be clear, here are the exact files that my service needs access to:
interface: personal-files
read:
- $HOME/.vimrc (for reading current vimrc, and monitoring for changes)
- $HOME/.bashrc (check if alias already exists for ssh)
- $HOME/.zshrc (check if alias already exist for ssh)
write:
- $HOME/.vimrc (create vimrc file if not exist so inotify can watch it)
- $HOME/.bashrc (write alias for ssh if not exist)
- $HOME/.zshrc (write alias for ssh if not exist)
- $HOME/.ssh/viSSHous (ssh config which store base64 encoded vim configuration to be passed through ssh )
@gwolf3 there are a couple things to change with your snapcraft.yaml - first, write implies read so there is no need for both - second, each personal-files instance should be named with something descriptive so the user can have some knowledge about what is being granted. As such, I suggest the following changes to your snapcraft.yaml:
But I also have a few questions - why is there a need to be able to modify the users shell configuration? (ie. write access to .bashrc/.zshrc)? Also if a user already has a vim configuration on a remote server, will this automatically overwrite that? Does it also automatically overwrite the local vim configuration? If so, how does it handle conflicts between the remote vim config and the local one?
Thanks for your suggestions. Those changes make sense and look good - I will make those.
As for your question, let me answer those as well:
Q - why is there a need to be able to modify the users shell configuration? (ie. write access to .bashrc/.zshrc)?
A - I write to the user’s zsh or bash rc file in order to create an alias for ssh, which points to the $HOME/.ssh/viSSHous config file for connection, rather than using the default .ssh/config. I made this choice to keep the viSSHous config seperate from their standard ssh setup - the other way to do it without using this alias would be writing directly to .ssh/config. I could also “Include” .ssh/viSSHous from .ssh/config, which would accomplish both, but this is limited to users running open-ssh client 7.3 and above, and is a bit more finicky.
Q - if a user already has a vim configuration on a remote server, will this automatically overwrite that?
A- Yes, but only for that user which is logging in. It will overwrite with the local vimrc configuration.
Q - Does it also automatically overwrite the local vim configuration?
A - It does not overwrite the local vim configuration at all, but rather only reads the local vim configuration and watches for changes. The only reason for write access to .vimrc is to create it if it doesn’t exist so that the watch process does not error.
Q - how does it handle conflicts between the remote vim config and the local one?
A - the local vim config is always used as the source of truth, and will overwrite the remote.
I have concerns about the modification of the user’s own shell configuration - this does not seem like something that would be expected or obvious to me as a user of the snap and so I would suggest that this snap instead encourages users that they create this alias manually if they so desire rather than trying to do it on their behalf.
Also I don’t think it should have or need write access to the local vim configuration - if this does not exist, I don’t think it should just automatically go and create it - instead, it should signal this to the local user. This also gives me concern since if say I were to run this for the first time without a local vim configuration, it would create an empty one - then I might log into a remote ssh server and whatever vim configuration may have existed there would automatically then get overwritten with a blank one. This seems like a bad outcome.
Does the snap ask the user if they want to overwrite the remote config before doing so?
Also allowing modification of the users shell configuration would allow a snap to access other files arbitrarily (since it could add code to run anything it wishes the next time the user spawns a shell) all outside of confinement - so -1 from me for write access to ~/.bashrc / ~/.zshrc etc.
-1 from me for write access to ~/.bashrc ~/.zshrc, as this effectively nullifies snap confinement.
-1 from me for write access to ~/.vimrc. ~/.vimrc can contain vimscript, so allowing ViSSHous so write to ~/.vimrc could also allow arbitrary code to be run and circumvent snap confinement. In the event that ~/.vimrc does not exist, one option might be for ViSSHous to set an inotify watch on $HOME and wait for ~/.vimrc to be created.
-1 from me also for ~/.vimrc etc since as @msalvatore points out this could also allow sandbox escape.
Finally, I suspect that since you were using an alias to launch ssh with the $HOME/.ssh/viSSHous specified, that instead this configuration could live under the snap specific $HOME of ~/snap/visshous/<revision>/.ssh/viSSHous and so -1 from me for that too.
-2 votes against, 0 votes for personal-files access to ~/.vimrc / ~/.bashrc etc.
-1 votes against, 0 votes for personal-files access to ~/.ssh/viSSHous - this has not met the required votes. Can other @reviewers please vote on this (although I suspect without the other 2 this is now moot).
-1 from me also. I think read access would make sense to understand/import/use user configurations, but changing outside the source program(s) can be tricky. A workaround could be to read the configurations, import them into snap-specific configuration and write subsequent changes there.
