Please, review "ktor" snap for a "classic" confinement

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.

Could you please approve this snap? version 2.0.0-eap-5

plase see Process for reviewing classic confinement snaps

classic confinement will only be granted by the reviewers if your tool fits into the list of “supported” categories …

access to ~/.ktor/ktor.rc can actually be achieved easily via the personal-files snap interface …

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 …

Oh really? That sounds great, then , thanks :slight_smile:

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?

Note: you can check the workflow of the tool here:


  • ./ktor-cli-generator-3.kexe generate <project-name> :
    • Creates ~/.ktor and ~/.ktor/ktor.rc
    • Checks whether JDK of the desired version (11) exists and if not so, downloads it manually from openjdk archives, and then puts into ~/.ktor/jdk
    • Sets local (application-scoped) environment variable JAVA_HOME for the running application process
    • Runs ./gradlew in the current working directory subpath in order to download Gradle of the compatible version.
    • Note: it also has to execute ~/.ktor/jdk/...../java locally from the ./gradlew script (which gets rejected by snap)
  • ./ktor-cli-generator-3.kexe start <project-name> :
    • Executes ./gradlew run and passes some arguments to an application.
    • Note: it also uses the JAVA_HOME and the JDK from the step above

Hi! Any updates so far?

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.

Thanks a lot for your reply!

does this snap expect to execute gradle or the JVM that is installed on the host?

Correct! It will either execute the existing JVM or download a new one in case the existing JVM is not compatible.

So, we need both permissions: to execute existing installed software and to download a new one if it doesn’t fit our needs.

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:

  1. they are not installable on Ubuntu Core (all snaps) devices
  2. 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:

  1. 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)
  2. 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/ (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.

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