ropen is a remote files opener that works with terminalpp. It works by reusing the existing terminal connection and passing any local file to the terminal so that it can then be opened locally on the same machine that runs the terminal.
In order to do this, the ropen app must have access to all files the user logged in the session has access to.
I am the developer of the application (and of terminalpp which already has classic confinement). Please let me know if you have any further questions and thanks for your time!
To clarify my understanding, ropen would be installed on the remote machine and is used to encode a particular file as specified by the user and send this back for display to terminalpp? In this case, ropen itself may not need to access all files which the remote session could - instead I could imagine using a shell function and doing something like:
function ro {
if [ ! -z $1 ]; then
cp $1 $HOME/snap/ropen/common/
ropen $HOME/snap/ropen/common/$(basename $1)
rm $HOME/snap/ropen/common/$(basename $1)
fi
}
ie. instead of giving ropen full access to all files at all times, when you want ropen to have access to a file, copy it into ropen’s private per-snap storage area, then invoke ropen with that copy, and then remove that copy when done. This way the user only grants ropen access to each file as it is needed, rather than all at all times - as well as the ability to do anything else to the system by being unconfined as a classic snap.
Yes. the ropen itself does not technically need access to all files and a script like yours can be used to make it work. There are following issues though:
one of key functionalities of ropen is that the terminal keeps track of same files from same hosts and overwrites them when needed. This would be lost now.
ropen is also released as a deb and rpm package and on macOS so I would like the same name to work the same on all platforms
future versions of ropen will be more involved and would actually allow remote editing and this I fear would be impossible to do from within the confinement…
AFAIK the script would need to be written by the users themselves, therefore complicating the installation process
But your security concerns are of course valid. After a thought, would this be a reasonable compromise?:
I can get rid of (1) by providing an extra argument to ropen where the filename can be specified and the script would set it. I would still very much like the same name to work on all platforms, i.e. I hope ropen will get the classic confinement on snapcraft. I will however also create another snap, say ropen-safe that will be confined and will use the method you propose and I will link the two apps together so that users can decide on their own?
I am not sure that it is a great user experience to have a -safe version of the snap since this would imply somehow that the non -safe version was somehow unsafe… instead you could have a -classic version but I also fear that this leaves users to make a choice which they should not be expected to make - in this case, since terminalpp is already classic and ropen is used with terminalpp perhaps it makes more sense to have this be classic as well to avoid user confusion in either having to setup weird bash functions etc to make it work as strictly confined - I was going to suggest that for viewing files system-backup might be workable BUT if you intend to allow editing of files this is not going to work (since it provides only read-only access to files).
Which leaves me to think that classic confinement might be the most appropriate solution for ropen - @reviewers thoughts?
As no other reviewers have weighed in on this one, due to the above reasoning I think the most appropriate choice for ropen is classic confinement due to the need to access or modify arbitrary files on the host and so the requirement for classic confinement is understood. The publisher has been vetted previously as well. Granting classic confinement for ropen - this is now live.
