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.
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)
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!
Given then Runlet needs to be able to execute arbitrary binaries to facilitate its core function.