I am the co-creator of Runlet (https://runlet.app). We just released the first version and we would like to publish in the snap store with classic confinement. We believe that classic confinement is a very important requirement to Runlet due to its ability to create jobs that can perform actions in any aspect of the operating system. This includes create files, access system devices, run processes as root and so on.
We have analysed some alternatives to the classic confinement (such as home plug) and we find it very limiting to Runlet.
Please let me know if there’s any other information that we can provide to help you in this process.
Can you detail some use cases that actually require the classic confinement that cannot be achieved with strict confinement and interfaces? Alluding to a need to create files and access system devices is not detailed enough. The reviewers need to know what your app is designed to do, how it does that - specifics for 1 or more example uses, and why it cannot do that under strict confinement.
Absolutely! With Runlet, users can define scheduled jobs. One use case to that is to perform system upgrades (apt, yum, eopkg, …) at a defined point in time. In fact, users can define any script or command to be run by Runlet. Another use case, we collected with our potential clients, is to perform data analysis using a cluster of GPUs. The cluster and all their software architecture are managed by Runlet. We believe that in strict confinement we can not unveil the full potential of Runlet to our users.
We think that in strict mode we can not offer the following features to our users:
- allow users to execute any sort of scripts and commands (root and non-root) in Runlet
- access any file or device of the operating system
- access to any service that is running in the system
Please let me know if you need more information. We will happily provide it to you.
Given then Runlet needs to be able to execute arbitrary binaries to facilitate its core function.
+1 from me too, and I’ve vetted the publisher.
This sounds not that different from cron/at/launchd/systemd timers and in some ways but is cloud based (per their FAQ and synchronizes the jobs across a fleet of devices. In some ways this is therefore like a management snap, which we do not allow, but also like conda, which we did allow because the in that the user is telling the snap precisely what to do. It is understood that classic is required and I feel it is sufficiently within the same scope as conda that it should be allowed. @pedronis, please speak up if you disagree.
(I’m going to give @pedronis some time to respond before granting this)
Granting use of classic. This is now live.
@jdstrand I’m missing completely how this is like conda tbh? aren’t the jobs defined on the web and not locally?
I ungranted classic until things are clarified.
Hi @pedronis We have a daemon (runs on the user’s machines) and an electron interface (connects to the daemon locally). The user can create jobs on the user interface or via cli using the daemon. The daemon is responsible for running the jobs the user created and triggered. The user is responsible for job creation which can be whatever they want, thus be able to run any sort of commands.
I’m probably misunderstanding something, will there be some way to define jobs from a centralized or self-hosted cloud service? (I’m trying to parse what “cloud-based” in the tagline refers to)
@GustavoKatel - also in addition to @pedronis question, is there a runlet agent that runs on the cloud instances, such that when the user creates jobs via the electron interface, those jobs are pushed to the cloud instances’ runlet agent? Is the runlet agent also snapped or just the electron ‘job creator’? Forgive me if I’m misunderstanding how this works. If I am, please consider the details in my question when correcting me to provide that level of detail. Thanks!