Request for classic confinement: lazyjournal

store-requests classic-confinement
1
  • name: lazyjournal
  • description: A TUI for reading logs from journalctl, the file system, Docker and Podman containers, as well as Kubernetes pods, for quick viewing and filtering with fuzzy find, regex support, and colored output. Written in Go using gocui.
  • snapcraft: https://raw.githubusercontent.com/Lifailon/lazyjournal/refs/heads/main/snapcraft.yaml
  • upstream: github: /Lifailon/lazyjournal
  • upstream-relation: The snap publisher is the upstream developer and maintainer.
  • supported-category: log viewers, system utilities, container management, kubernetes tools
  • reasoning: The existing strict confinement interfaces are not sufficient for lazyjournal because the application requires deep integration with the host system to function properly. Specifically:

  1. Access to journalctl system logs
    lazyjournal needs to read logs from journalctl, which involves accessing /run/log/journal/ and /var/log/journal/. These locations are not accessible under strict confinement.

  2. Docker and Podman container integration
    The application reads container logs, inspects container metadata, and monitors process namespaces, all of which require access to /var/lib/docker/, /var/run/docker.sock, /var/lib/containers/, and container-specific mount namespaces. These operations are not possible within strict confinement.

  3. File system access across various paths
    lazyjournal is designed to let users explore arbitrary logs across different system paths, including log directories not mapped inside the Snap sandbox (e.g., /var/log, user-defined paths, and persistent storage). The home, log-observe, or system-observe interfaces do not provide sufficient access for this use case.

Because these operations require access to unrestricted system resources, classic confinement is necessary for lazyjournal to function correctly and provide its intended features.

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

This is fully supported (including execution of journalctl itself) by log-observe

Most of this should be covered by the docker-support interface (if something is missing, it can perhaps be added)

This is typically not a reason for classic support (in fact i think it is explicitly stated as unsupported in the list of supported stuff for classic)

What exactly were the issues when you tried the interfaces, perhaps we can adjust them for your use case ?

4

adding tracking tag for our automation (#askForInfo)

5

Thank you for your reply and for the clarification.

Let me provide more specific issues I encountered while trying to work under strict confinement:

1. Access to journalctl logs (log-observe)

Although log-observe allows executing journalctl, it does not provide access to /run/log/journal/ or /var/log/journal/ when they are only accessible to root or systemd-journal group.

Since lazyjournal is a TUI running under a user session, and Snap apps are confined, it cannot read the binary journal files directly — only limited filtered data from journalctl can be accessed, and even that doesn’t always work if system permissions are strict (as on some servers). My app sometimes parses logs directly for performance reasons.

2. Docker and Podman access (docker-support)

Even when using docker-support, access is limited. For example:

  • I cannot enter container mount namespaces (nsenter) to read logs from inside containers.
  • I cannot inspect Podman logs, since docker-support is focused on Docker specifically, and Podman uses different paths like /var/lib/containers/.
  • Access to /var/run/docker.sock is allowed, but not to Docker’s internal /var/lib/docker/containers/*/config.v2.json files, which are needed to resolve container names and log paths.

These are essential features in lazyjournal — users expect a unified way to browse all containers, regardless of runtime.

3. Filesystem access

I understand that file access alone is not a justification for classic confinement. However, in this case, lazyjournal allows the user to manually browse arbitrary log directories, including:

  • External mount points (e.g., /mnt/logs)
  • Logs in backup folders or external drives
  • User-defined custom paths for log collection

This is not something that can be predefined via interfaces like home or removable-media, as they do not allow traversal of arbitrary system-wide paths.

If any of the above can be achieved through specific interface combinations or upcoming improvements in Snap confinement, I’d be happy to adjust the Snap to use them. However, in its current form, the tool’s goal is to provide unrestricted log viewing and filtering from all major sources — journal, containers, filesystem, and Kubernetes pods — which is why I initially chose to request classic confinement.

Thank you again for your consideration.

6

Hey @Lifailon

From my point of view this snap does not clearly fit in any of the supported categories for classic confinement. Thus, I would like to hear @pedronis opinion on this one.

7

Well, classic wont change that, if your user is not in the systemd-journal group neither strict nor classic will have access, the confinement you select wont do anything to the filesystem permissions or groups the user is in …

The missing support for nsenter is probably worth checking if we could have that added to docker-support …

Alternatively it perhaps makes sense to have a whole separate “container-log-observe” interface that covers multiple container solutions and could also cover podman then, but you are correct here, today docker-support will likely not be enough.

This is fully covered by removable-media, it gives you full access to any filesystem mounted under /mnt or /media

If the external drives are mounted in either /media or /mnt you’d have access (see above).

For custom paths and backup drives the system-backup interface might be usable to gain read access to such dirs …

8

Thank you for the detailed explanation!

Unfortunately, the current confinement model (even with log-observe, docker-support, and removable-media) does not suit my application’s use case. My app (lazyjournal) is a TUI for reading logs not only from the host system but also from Docker and Podman containers.

The issues I’m facing:

Access to journald logs is not possible, even though the user is in the systemd-journal group — this is due to sandbox limitations.

Access to container logs is not possible:

I cannot access /var/lib/docker/containers/** where the logs reside.

Podman is completely unsupported since it uses different paths (/var/lib/containers, etc.) not covered by docker-support.

Even if the user is in Docker groups, I don’t see the list of containers after building strict and the docker-support plugin (under the hood uses docker cli subprocess). The situation is similar with logs, I see only a small part (less than 5%) of all available to the current user without root.

The key problem is that there are many restrictions, but the application is already adapted to work in user and root mode, and setting access rights will complicate its use, in classic mode everything works correctly.

9

Hi again,

Just following up to see if there’s any further feedback or if I should expect a decision regarding classic confinement for lazyjournal?

As mentioned earlier, the app is fully functional in classic mode, but the current strict interfaces (including log-observe, docker-support, system-backup, etc.) do not provide sufficient access for key functionality, especially when reading from journald, Docker, and Podman logs.

If there’s anything else I can provide to support the review or if there are specific changes you’d like to see in the snapcraft.yaml or documentation — I’m happy to update it!

Thanks again for your time and guidance.

10

Your package doesn’t fit in any supported categories but can also not be fully covered by existing interfaces which is why Jorge summoned an architect above, only architects can permit an override like this where a snap doesn’t fit in any supported and pre-defined category, so you will have to wait until one finds the time to review your request…

1 Like