Hi!
I am from Ktor team from JetBrains and we’ve created a ktor snap which allows you to generate new Ktor projects.
The API is pretty simple:
ktor generate
ktor start
ktor --help
We need a classic confinement for that as it writes to files like ~/.ktor/ktor.rc and also it writes to the current directory. We are targeting newbies and newcomers and we don’t want to require our users to manually connect any interfaces so the best option would be for them to simply write one line “snap install --beta --classic ktor” and that’s it.
personal-files indeed can work, but it it says “AUTO-CONNECT: No” in documentation. Which is not handy at all to write a series of connections instead of just one install.
it requires just one store-request post (like this one here) to ask for auto connection … if the snap is the clear owner of the dir, it is usually a no-brainer to get it granted …
Ok, I will remove this request for classic from our internal queue - please feel free to create a new topic regarding auto-connect and use of a personal-files instance instead.
Hi! W also need to run gradle, download specific JDK and run it. And snap does not allow us to execute stuff or make something executable, apparently.
Other than that, we’ve checked the list of supported types of applications and we actually fall into the category of " * tools for local, non-root user driven configuration of/switching to development workspaces/environments" . We are indeed configuring a development enviroment for JVM+gradle+kotlin+ktor development installing specific versions and changing local environment variables as well as accsessing and executing files in the current working directory and executing files in $HOME directory. We’ve experimented with personal-files and other interfaces and that seems to be still impossible with the strict confinement.
So this means that we can get a classic confinement, correct?
So based on the updated information, I agree that this snap falls within one of the supported categories for classic confinement, ie. “tools for local, non-root user driven configuration of/switching to development workspaces/environments”.
However, to clarify, does this snap expect to execute gradle or the JVM that is installed on the host? Since your comment above seems to suggest it would download a JVM and execute that - and this is possible as a strict snap since a snap has write and execute permission within $SNAP_USER_DATA etc - also $HOME is set to ~/snap/<snap-name>/<revision so you should be fine to write to $HOME/.ktor by default as well under strict confinement.
So instead of using the read users $HOME if you use the snap-specific $HOME then it should just work under strict confinement from what I can see, and thus classic confinement should not be required.
Hmm so since it can download and execute a new JVM then wouldn’t this be the preferred option - making a snap classic comes with other limitations - as noted in Process for reviewing classic confinement snaps
Classic confinement sometimes might seem like the perfect solution to a publisher’s problem, but snaps that use confinement: classic differ from strict mode snaps in important ways:
they are not installable on Ubuntu Core (all snaps) devices
they run in the global mount namespace (ie, the host’s filesystem) as opposed to what is specified by base in the snap’s yaml.
Because of ‘2’, great care must be taken for the snap to work reliably across all distributions since, for example, as part of the build process snapcraft will adjust the snap’s binaries through binary patching and/or setting environment variables to look into the $SNAP directory for paths, either of which could affect the snap’s reliability when running on arbitrary cross-distribution host filesystems. In contrast, strict mode snaps use what is specified by base in the snap’s yaml as the basis for its root filesystem at runtime and can depend on it not changing.
So it is preferred that snaps run as strict mode where possible - in this case, it would seem ktor can run under strict confinement so I really suggest you pursue this option.
Thanks for your reply!
We did some experiments with strict confinement and always installing JVM and now get back to you. We figured out that there are some other requirements of our app:
We also download gradlew script that ships Gradle of a compatible version and installs it into your system if it is not ther or reuses an existing one (that is how gradlew works).
It also requires an execution and read/write permissions for the whole subdirectory of ~/.gradle/wrapper/dists/gradle-7.4-bin (there are really a lot of files and subfolders and for some reason personal-files only work if I specify each file explicitly. Just giving a write permission to the directory does not work. That is what snappy-debug tells)
We also run ./gradlew build and ./gradlew run commands in order to build and to run the generated project.
What snappy-debug tells is the following:
It is missing an access to ~/.gradle/native/<some hash>/linux-amd64/libnative-platform.so (mmap)
It is missing an access to read /proc/<number>/mountinfo
It is missing an access to write ``/.local/share/kotlin/daeon/kotlin-daemon-client-tsmarker.tmp`
…
and so on…
So, gradle and kotlin compiler use quite a lot from the system and some of these file names can not be known before the runtime.
Other than that, downloading a JDK if it already exists is not the best option for our users given that it takes additional time and some users may be unhappy if we install some extra JDK on their machine.
We understand the limitations but:
a) Ubuntu Core is not our target. As far as we understand, it includes embedded systems and IoS which is irrelevant target for a development environment.
b) We still need the access to the system because of gradle and kotlin compiler as described above.
There are other snaps that ship the gradle wrapper and after plugging personal-files (so they have access to the ~/.gradle directory) they can stay under strict confinement. Have you explore that option? (This post can be of help). I also think you can explore using personal-files to access the kotlin related files.
So I still think ktor can plug some interfaces, stay under strict confinement and therefore enjoy all the benefits of a stable runtime environment. Please also remember that classic confinement snaps run without restrictions, and thus use of classic confinement effectively grants device ownership to the snap.
@ktor-team - since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks
