I am requesting the snap ‘ltext’ to have a classic confinement.
It is a command-line tool intended to aid developers with processing text files - they can use it to compile arbitrary configuration files, html files under /var/www, or any source code files (so long as they’re UTF-8 encoded) - this freedom means that the executable shouldn’t be restricted in what files it should have access to, as developers should be free to use it throughout their system.
You can see the relevant line of code here: https://github.com/ltext/ltext/blob/master/app/Main.hs#L140
This is where ltext turns top-level expressions (references to file paths) into the text document contents. When invoking ltext, you provide an expression that references filenames like ltext "./foo ./bar", and each filename referenced needs to be readable. Developers could supply any file path to ltext and use it in any context - within system configuration files, cron daemons, or web servers.
Classic confinement for ltext would suit it best due to this issue. However, it doesn’t actually write anything on its own - it only reads files and sends the results to stdout.
Hi @athanclark
Thanks for submitting this request. According to the process for reviewing classic snaps, we require that the request fit into one of the supported categories. Could you please identify if ltext fits within any of those categories?
@0xnishit Yes, the most applicable category for ltext would be “compilers” - it takes an expression, does some typechecking, evaluates the expression using beta and eta reduction, then creates output and renders it to stdout.
@0xnishit I am requesting an update on this matter - Will I have to adjust the snapcraft.yml field to reflect the new category? Please let me know if there’s anything I can do to ensure the change to classic confinement for ltext.
If you just need read access to the entire system, we have some snapd interfaces that should help. Could you could try using the system-backup interface which exposes the host filesystem under /var/lib/snapd/hostfs?
This would be preferable from the review team’s perspective as classic is something we try to avoid granting unless absolutely unavoidable.
@dclane Hi, I just tried using this, and I am not sure if I’m using it right. /var/lib/snapd/hostfs doesn’t seem to have any contents… was it supposed to be a read-only interface to the whole /?
Regardless, I feel like this is pretty clunky. ltext is supposed to be used very similarly to grep, or even cat - if a snap for grep existed, would it be classicly confined, or distributed with a different interface?
-1 from me for using system-backup in this case - this interface is intended for applications that are expected to read the entire system contents (like a backup application), not for arbitrary applications that want to read usual user files etc. In this case, home and potentially removable-media seem sufficient for the majority of use-cases.
Thanks @alexmurray, you make a good point. I have probably overstepped the boundaries of what system-backup is intended for when I’ve recommended it’s use here. In retrospect, I agree and think we should limit (at least as far as auto-connects are concerned) the snap’s scope to home, which is in line with the confinement that users would expect from snaps in general.
Apologies to @athanclark for my flip-flopping on this.
