Classic confinement request for cric

store-requests
1


So cric is a gui for Java’s jlink command, used to make custom runtime images.

The cric snap contains it’s own custom runtime (command produced by cric) so it runs fine.

It’s up to the user of cric to provide the jlink command, JDK’s and jmods to work with, it can be from many providers and for many operating systems and in many different versions.

The problem is that in strict mode, cric is limited to home and removable-media,
that’s the reason for this request.

I first started out here and is open for other working suggestions than classic confinement.

Here’s a working snapshot of the snapcraft.yaml

name: cric
title: CRIC
base: core18
version: 1.0.1
summary: A Java jlink ui - a Custom Runtime Image Creator
description: |
    **CRIC** is a gui for the Java jlink command.

    It produces custom runtime images, kind of Java Runtime Environments.

    The driver behind CRIC was the need to create cross-target custom runtime images for the non-modular application https://mapton.org.

    https://github.com/trixon/cric

grade: stable
architectures: [ amd64 ]
confinement: strict
icon: snap/gui/cric.png
license: Apache-2.0

apps:
  cric:
    command: bin/launcher
    extensions:
        - gnome-3-34
    plugs:
        - home
        - removable-media

parts:
  cric:
    plugin: dump
    source: https://github.com/trixon/cric/releases/download/v$SNAPCRAFT_PROJECT_VERSION/cric-$SNAPCRAFT_PROJECT_VERSION-bin.zip
    #source: /root/project/cric-$SNAPCRAFT_PROJECT_VERSION-bin.zip
    source-type: zip
    organize:
      '*' : cric

  launcher:
    plugin: dump
    source: snap/local
    organize:
      'launcher': 'bin/'

  apt:
    plugin: nil
    override-build: |
        apt install openjdk-11-jdk -y

  jlink:
    plugin: nil
    after: [apt]
    override-build: |
        rm -rf $SNAPCRAFT_PRIME/jre

        jlink --no-header-files \
            --no-man-pages \
            --strip-debug \
            --compress=1 \
            --add-modules java.base,java.datatransfer,java.desktop,java.logging,java.prefs,java.sql,java.xml,jdk.jfr,jdk.unsupported,jdk.unsupported.desktop \
            --output $SNAPCRAFT_PRIME/jre

        strip -p --strip-unneeded $SNAPCRAFT_PRIME/jre/lib/server/libjvm.so
2

@trixon, hey. As you probably read in our Process for reviewing classic confinement snaps, the need to access to arbitrary files on the system falls under the unsupported category for requesting classic confinement.

I see you are already plugging home and removable-media, have you considered personal-files and/or system-files as well?

3

@trixon - ping, can you please provide the requested information?

4

I’m sorry about the delay .

No, I did not consider that, I might take a look at it.

My main concern with non-classic, except the “limitation of file access”, was the user friendliness of it all, but now that ogra helped out below I think I have a solution in reach. :slight_smile:

1 Like
5

@trixon based on your last comment it seems you will be able to keep your snap under strict confinement, is that correct? If that’s the case could you please edit this request title and detail here which specific interfaces you will require? Remember the use/auto-connection of some interfaces require approval Process for aliases, auto-connections and tracks.

Thanks!

6

Yes @emitorino, I’m able to continue with strict confinement.

Auto-connection for removable-media would be nice, but when reading your link I don’t think cric falls into the listed cases. Do you agree?

If so, how do I close this request?

7

Hey @trixon,

As you have confirmed it is not needed, we are removing your request for classic confinement from our internal queue and there is nothing else you need to do from your side. You might want to mark the comment/answer that helped you with your needs as Solution and that should be all.

Regarding auto-connection for removable-media, if this is not a hard requirement for your snap to properly work, its preferred to have the snap user taking the decision to do it instead. This is because, as you might have read, all snaps with this interface connected have unrestricted access to all data from any plugged media.