Request for Classic Confinement: ainfovac

store-requests classic-confinement
1

name: ainfovac

description: AinfoVac is a comprehensive Enterprise Resource Planning (ERP) system developed in Gambas 3, specifically designed for the technical and economic management of livestock and agricultural farms.

snapcraft: PRIVATE (Local build)

upstream: http://www.ainfogra.com (Private repository)

upstream-relation: I am the upstream developer and author of the project.

supported-category: Hardware interaction/device synchronization (ADB/USB) and legacy data management.

reasoning: We are requesting classic confinement due to critical architectural and functional constraints that make adapting to strict confinement unfeasible without completely rewriting the software:

  1. Mobile synchronization via USB and ADB (Android Debug Bridge): AinfoVac works in tandem with an Android mobile app used by farmers in the field. To synchronize local SQLite databases without relying on internet connectivity (often unavailable on farms), the desktop application connects directly to mobile devices via USB using ADB. Strict confinement blocks arbitrary access to USB ports and communication with the host system’s ADB server, completely breaking the tool’s core synchronization feature.

  2. Manual backups and data portability (~/.ainfovac): Our user base in the primary sector is accustomed to performing backups and migrating to other machines simply by copying the ~/.ainfovac directory located in their real home folder. Under strict confinement, this data is hidden and isolated within the virtualized Snap structure (~/snap/ainfovac/current/...), preventing users from performing their traditional workflows and severely increasing the risk of data loss. Additionally, the application requires access to static system paths like /usr/share/ainfovac for its initial database deployment.

  3. Native security restrictions of the Gambas 3 interpreter (gbr3): The Gambas 3 runtime performs hardcoded security checks on the ownership and permissions of its temporary execution directories (/tmp/gambas.$UID). When running inside an isolated Snap in strict mode, the discrepancy between the virtualized user and the host system causes the interpreter to block execution for security reasons (throwing the error “Do you try to hijack Gambas?”).

Rewriting the mobile sync architecture, the database persistence logic, and bypassing the interpreter’s native security checks is technically unfeasible for this consolidated software.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

2

This request has been added to the queue for review by the @reviewers team.

3

Please note that only categories from the supported list at the site below will be able to get classic confinement granted, this is a hard requirement, I fear your app does not actually fit into any of the listed categories …

Note that there is a raw-usb as well as an adb-support interface you can use in strict confinement and there are other applications in the store using ADB without issues under strict confinement (here is an example: Install UBports Installer on Linux | Snap Store ).

To make your application use ~/.ainfovac you can simply use the personal-files interface and to help your application finding /usr/share/ainfovac we have the layouts feature to re-map this into a writable space the snap owns…

Your third point is not really clear, I’d expect you to ship the gambas runtime in your snap so there would not be any discrepancy at all, the /tmp dir is owned by the snap so the user should have access, but if this does not work you can trivially set TMPDIR=$XDG_RUNTIME_DIR in your snapcraft.yaml, that will make sure a user owned dir is used as /tmp …

1 Like