Hi,
I’m not sure who to reach out to for this. I have a snap called “croc” and users are experiencing problems with croc snap reading/writing dot-files in their HOME directory.
To alleviate this I added the personal-files plug. However, now I’m unable to push new versions to snap as it says “Manual review pending”: https://dashboard.snapcraft.io/snaps/croc/revisions/96/
I’m not even sure personal-files is the right plug. Can someone please let me know?
Thanks.
Hi @schollz, dot-files often contain sensitive data, which requires more consideration to allow access to.
One option for you is to switch to classic confinement, which would allow you access to those files.
personal-files requires a specific list of paths that will be accessed, so unlikely to be what you’re after.
To remain strict, one potential option would be to use standard input and output to feed the file data in / out - at that point croc does not need access to the files - but it would not know its size, so progress reporting would be problematic.
@Saviq thanks for the response . I think that classic confinement is the best approach as it is the best at keeping the workflow consistent with the regular binary. How do I go about requesting classic confinement for croc?
if there is a possibility that your app can work with interfaces it is very unlikely you get granted (insecure) classic confinement … classic is really an exception, not the rule here …
if you can cover the files you need by using personal-files you should rather do that and ask for manual review feedback. if your app clearly can ot work at all and personal-files is proven to not help, you can ask for classic …
@orga Thanks for your input.
After looking at personal-files I really don’t think it will work. croc is a file-transfer utility so it could access any file in the home directory. There’s no way of me knowing what files dotfiles users will want to access.
I think @Saviq’s suggestion to suggest to users to only pipe does work (e.g. cat ~/.vimrc | croc send instead of croc send ~/.vimrc) but, as stated, this loses out on some of the nice benefits of the utility (namely progress, sending directories, resuming transfers, etc.).
If classic confinement is not possible, then I think I’d opt for removing croc from the snap store. This is my least favorite choice because I’d like to keep croc widely available, but I don’t see how it can be done without creating more UX issues to deal with.
Note that classic confinement prevents you running on Ubuntu Core, and has its own set of cross-platform problems (the snap sees the host’s root filesystem rather than that of your base).
Ok thanks. I’ll think about this.
@schollz - can you describe a few typical use cases for croc? Based on the bug report it seems that most users would simply benefit from the snap plugging ‘home’ and ‘removable-media’. If the snap needs access to all files on the host, ‘system-backup’ is also an option (access through /var/lib/snapd/hostfs). If dot files are a prime use case, please list a use case or two for that as well. Thanks!
@jdstrand Sure.
croc is a tool that allows you to transfer (send or receive) file or folders from one computer to another.
The bug report is because someone wanted to send a $HOME/.config file, but they could have wanted to send any file at all.
I think system-backup would be good to eliminate some friction for sending files, but wouldn’t there still be an issue for receiving a file (e.g. into a dot directory or some place other than $HOME)?
It would affect receiving files, yes, since system-backup does not allow writes. Access to arbitrary dot files in $HOME is not a supported use case for snaps (see Process for reviewing classic confinement snaps).
As mentioned in this topic, this would be a documentation point for your snap: either use the pipe method or have the user put the file in another location that is allowed to the snap. croc could be updated to guide the user if it detects it is running as a snap and tries to access a top-level dot file/directory in $HOME.
