Request for classic confinement approval for snap ltext

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: 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.

Thank you!

Hi @athanclark

Sorry for the delay, thanks for bumping this.

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?

Did you connect the interface with snap connect ltext:system-backup ?

I put a demo snap on github that just uses cat and it works ok: filesystem-reader.

If cat or grep were snap’d, I think this is how they’d be done.

We can grant an auto-connect for system-backup so that it doesn’t require that manual connection step.

@dclane Yes I think this works! Thank you for your help!

1 Like

Can i get some votes from other @reviewers on whether an auto-connect of system-backup seems appropriate for ltext? Thanks.

system-backup seems the right option to me here, instead of running the application without confinement. +1 from me

-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.

Thank you all for your help. I think the current permission setup, where home is automatically enabled is suitable for most needs of ltext.