description : Free multi-platform database tool for developers, SQL programmers, database administrators and analysts. Supports all popular databases: MySQL PostgreSQL, MariaDB, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Derby, etc.
reasoning : Access to resources outside the sandbox is needed. We’re experiencing a variety of issues accessing resources outside the sandbox. For example, opening Excel spreadsheet data, database dump issues due to insufficient permissions to the required directory, and embedded databases also failing to open due to various access issues. Some access issues can be resolved with pluggable interfaces, but there are also issues where we don’t know which access rights are missing or which interfaces are required.
For example, the DataGrip snap package has a classic isolation level, and such issues with databases don’t arise there. We really need this too.
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.
I see, so it is used to build applications, run a compiler like gcc on the host that needs to access header files and libs when building the app ?
I.e. it is the same as intellij or visual-code (note this category is very specifically reserved for text editors and IDEs that spawn compilers) ?
If you just want to spawn excel sheets and such, there should be suitable XDG portals on the host that allow this if you make use of them in your app when you can not use the provided interfaces …
We’d like to explain why DBeaver requires classic confinement.
DBeaver supports over 120 different databases, each with its own permission set and specific behavior. These databases frequently change, and it’s impossible to anticipate every potential configuration or access scenario in advance. Because of that, classic confinement is the most suitable option. It ensures DBeaver can interact reliably with all supported databases without unexpected permission issues.
This challenge is even greater considering that DBeaver has several million users. When something breaks due to confinement restrictions, it immediately affects a large number of people.
For example, at the moment, some users cannot open DuckDB when using DBeaver the snap package
IO Error: Cannot open file "/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/snap.dbeaver-ce.dbeaver-ce-3208ba18-6c7e-4daa-9484-312742f68107.scope/memory.max": Permission denied
DBeaver is functionally very similar to JetBrains DataGrip, which already has classic confinement. We believe this setup is the most logical and consistent option for our product as well.
It looks like we stuck with the snap package as DBeaver needs to work with browser, with office apps and with unknown amount of third-party embedded databases which work with file system directly (e.g. DuckDB).
Sorry for the late response. First, I don’t think dbeaver-ce fits the usual criteria for the IDEs category.
Could you please share the apparmor denials you see when running the DuckDb application? It seems that the default template allows access read access to the system.slice but not to the user.slice, however it may makes sense to add it either to the template or to any interface. I’ll take a look
The issue with DuckDB is just one example of access restrictions. We also have other issues reported by users related to various access restrictions in other databases in the dbeaver-ce snap package. And, we’ll repeat again, DBeaver supports over 120 different databases, each with its own set of permissions and specific behavior. These databases change frequently, and it’s impossible to anticipate every possible configuration or access scenario. Each time, it takes a lot of time and involves multiple people to figure out which interface is needed.
DBeaver is not typically classified as an Integrated Development Environment (IDE) in the traditional sense; however, it possesses IDE-like capabilities.
DBeaver offers a robust SQL editor with syntax highlighting, code completion, formatting, and error detection—features typically found in database-focused IDEs.
The paid version supports debugging for stored procedures and functions in specific databases (such as Oracle, PostgreSQL, and SQL Server), a hallmark of IDE functionality.
It allows users to organize database connections, scripts, and metadata within a project-based workspace, similar to how IDEs manage code projects.
DBeaver includes tools for schema design, data modeling (ER diagrams), query execution plans, and performance tuning—all of which support database development workflows.
Built on the Eclipse platform, DBeaver supports plugins and can be extended with additional features, much like Eclipse-based IDEs.
We also have to bring up our close competitor, who we really appreciate for a tough fight for users, DataGrip. DBeaver and DataGrip have a lot of similarities relevant for this discussion:
Both based on without-a-question-IDEs (Eclipse and IntelliJ IDEA, respectively)
Both connect to databases using primarily JDBC. Users can bring their own unknown JDBC driver that might require something unknown in advance
However, DataGrip has been granted classic confinement, presumably, by passing the IDE bar set by the lovely folks from Snapcraft, while we haven’t. Without that, DataGrip would suffer from the same issues we are describing. In our mind, this uneven application of rules creates an unfair advantage for our rival.
Hey @dbeaver thanks for the additional context and reasoning
From my point of view, dbeaver-ce does not clearly fit the IDEs category or any other category for classic listed in the Process for reviewing classic confinement snaps. With that in mind, the only way for dbeaver-ce to get classic confinement is with the approval of snap architects. @pedronis can you take a look to this request?
