- name: lunodb
- description: LunoDB is a professional-grade, cross-platform database management client designed for developers and database administrators. It supports MySQL, MariaDB, PostgreSQL, SQLite, MongoDB, SQL Server, and Redis with AI-powered SQL generation, SSH tunneling, and advanced query capabilities.
- snapcraft: https://github.com/lunodb/lunodb/blob/main/build/snap/snapcraft.yaml
- upstream: GitHub - lunodb/lunodb: Modern, AI-powered database client supporting MySQL, PostgreSQL, SQLite, MariaDB, MongoDB, SQL Server, and Redis with voice dictation, multiple AI providers, and visual relationship diagrams.
- upstream-relation: Publisher is the upstream maintainer/author
- supported-category: developer-tools
- reasoning:
LunoDB requires classic confinement due to the fundamental requirements of professional database management software:
1. Arbitrary Filesystem Access
- Must open SQLite database files (.db, .sqlite, .sqlite3, etc.) from any location on the filesystem
- Import/export CSV, JSON, and SQL files to user-chosen directories outside $HOME
- Read SQL script files from project directories
- Create backup files in arbitrary locations
- Access SSH private keys from ~/.ssh/ or custom paths for SSH tunneling
The home and removable-media interfaces are insufficient as database files and SQL scripts are frequently stored in project directories, mounted drives, and custom locations throughout the filesystem.
2. SSH Tunneling with Arbitrary Key Locations
- Establishes SSH tunnels using the ssh2 library for secure remote database connections
- Must read SSH private keys from user-specified custom paths (not just ~/.ssh/)
- Must bind to local ports for tunnel endpoint forwarding
- Requires combined filesystem + network-bind access that cannot be satisfied by available interfaces
3. Native Node.js Modules
- Uses better-sqlite3 (^12.2.0) - native C++ SQLite engine addon
- Uses ssh2 (^1.17.0) - native SSH protocol implementation
- Requires loading shared libraries and executing compiled binary code
- Memory mapping and system calls that may be blocked by AppArmor profiles in strict confinement
4. File Association Handling
- Registered desktop file associations for .sql, .db, .sqlite, .sqlite3, .db3, .s3db, .sl3, and .lunobackup files
- Must accept and open database files from arbitrary filesystem locations passed as command-line arguments from file managers
5. Unrestricted Network Access
- Connects to database servers on any host, port, and protocol (MySQL:3306, PostgreSQL:5432, MongoDB:27017, SQL Server:1433, Redis:6379)
- Corporate environments frequently use non-standard ports for security
- Combined with SSH tunneling requires binding arbitrary local ports
6. Electron Framework Requirements
- Chromium renderer processes require specific system calls
- GPU acceleration and native window management
- Desktop notifications and system tray integration
Alternatives Considered: We evaluated strict confinement with interfaces (home, network, network-bind, desktop, desktop-legacy, x11, browser-support, ssh-keys, removable-media) but this combination still fails to provide:
- Access to files outside $HOME and removable media
- Ability to read SSH keys from non-standard locations
- Full native module execution without AppArmor restrictions
- Reliable operation across all Linux distributions
Classic confinement is necessary for this category of professional database tooling that requires system-wide filesystem access and network capabilities.
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.
Additional Notes:
- LunoDB implements security best practices: encrypted credential storage via Electron’s safeStorage API, parameterized SQL queries to prevent injection, and no telemetry without user consent
- Also distributed as AppImage and .deb packages, but Snap support is requested for users who prefer the Snap Store ecosystem