Hello,
I’m the maintainer. A user requested classic confinement. Looks fine to me as project lead.
Related discussion with technical reasons: https://github.com/ipfs/ipfs-cluster/pull/579
Hi,
Part of the process for granting classic is understanding why it is needed. Can you describe in detail the reason why this snap should be classic?
Thanks
Because the snap contains an utility ipfs-cluster-ctl. This utility should be able to read any file in the system to do ipfs-cluster-ctl add myfile.txt and apparently that doesn’t work now.
Thank you for the added detail. I’m not an ipfs-cluster user; would you very briefly describing what use case ipfs-cluster is meant to address and why ipfs-cluster-ctl add /arbitrary/path/myfile.txt is needed?
I’m specifically wondering why the home and removable-media interfaces are not enough because I’m assuming (perhaps wrongly, please correct me 
) that a user shouldn’t be able to ipfs-cluster-ctl add /etc/shadow, ipfs-cluster-ctl add /etc/shadow /dev/sda or ipfs-cluster-ctl add /home/otheruser/.ssh/id_rsa).
Hi! I’m an IPFS-Cluster user and I requested the modification.
IPFS-Cluster is a utility for pinning files from a system to their IPFS daemon and orchestrating backups of those pins across multiple machines. This could be any arbitrary file on the system, including /etc/shadow or /dev/sda if that’s what the user wants to do (subject to their own user’s permission limitations), and the files to be added may not necessarily come from a location within a user’s home directory.
In our particular implementation we would be adding files from a scratch space outside of the home directory but which the user has read permissions. Currently the snap confinement limits that workflow.
To be clear, by this you mean your use, but someone else’s use will be different? Ie, this scratch space isn’t something inherent to ipfs-cluster (which we could consider modifying snapd to accommodate) but rather that is a site-specific use by you.
Correct, this is my use-case, and others may have similar use-cases. As cluster management software, it’s going to be used in conjunction with other software to manage files across many machines, so an Apache daemon may drop uploaded files into a location that gets picked up by the IPFS Cluster daemon, for example, and it’s not convenient or intuitive to handle this orchestration inside of a home directory.
Due to the nature of the software it is reasonable and necessary that the client be able to pin files from anywhere on the system, providing that their user has access to them, in the same way that a user of Atom, VSCode, or other classic utility would need to be able to access arbitrary files throughout the system.
Please,
set confinement to classic. I don’t understand why we have to lose such time explaining how we want to deploy our own application.
Yes, users should be able to add files to cluster from whatever place in the filesystem they have access to. They also should be able to configure the datastore location in any drive or device, not necessarily the home, specially if it’s shared with huge ipfs repositories. That’s why this changed was merged.
Are snaps running by default as root user so that a classic confined snap can access /etc/shadow or ~/otheruser/.ssh ? Or do you recommend running them as root? Because otherwise I have no idea what you’re suggesting…
The requirements are understood and this mostly follows the pattern of backup software. @niemeyer, please speak up if you feel this doesn’t fit for classic.
@Wimpress, @popey, @Igor and/or @evan - can one of you vet the publisher and the snap?
Because classic confinement grants device ownership to the snap and the snap is in the public snap store, we limit the use of classic. We have processes for this that are described in Process for reviewing classic confinement snaps. In essence, we want to move to a world where classic confinement doesn’t exist, so part of the process for granting the use of classic is understanding the precise use case. Sometimes, that results in immediate changes to snapd that means the snap can stay strict. Sometimes it means that snapd can’t support the use case as a strict mode snap today. After the requirements are understood, we vet the publisher of the snap since after classic is granted, the publisher is free to arbitrarily change the snap, including adding daemons which can run as root.
+1 from me. The only problematic thing will be that the snap won’t auto-refresh to classic as the user needs to initiate that. New users will need to specify --classic, but existing users will likely need to remove/re-install, I believe.