1

I'm using Debian/trixie (current stable) and heavily containerised projects / applications via LXC/incus into unprivileged containers; each having their own isolated UID/GID range.

Most of the containers run (wayland-)GUI applications, so I'm passing the host's wayland socket into most of them.

ADDED: I'm running sway as compositor on the (non-containerised) host wayland is also running on.

What I'm now confused about is:

I can easily screenshot all screen(s) from within any unprivileged container, e.g. using grim.

While I'm aware that the socket -- looking at it as a file with its file permissions -- is either all or nothing (read+write or not, hence the protocol is bidirectional), I was still expecting the wayland idea already enforcing some restrictions by default.

As far as I know for UNIX sockets -- and the wayland socket is one -- the other side (in this case the wayland process) can actually determine which UID/GID is opening / performing operations on it and hence restrict read requests of areas it didn't draw by itself.. but now I'm speculating and potentially making the whole issue an A/B-problem.

So: what's my misunderstanding about supposedly restrictions being in place by default and/or how to restrict access from users/groups/processes/containers to only what they themselves were drawing on wayland?

Improve this question
3
  • the screenshot functionality is implemented by the wayland compositor, and that is the instance that can enforce access controls. What's your compositor? (you're significantly misinterpreting what that socket is used for. It's not giving applications some random memory access to all of the graphics. That's not how windowing systems work! And especially not wayland.) Commented Oct 1 at 15:23
  • Thanks and understood: I'm using sway as compositor and added that info in the original post. Commented Oct 1 at 16:03
  • Might be a potential duplicate of superuser.com/questions/1861408/… which of course I only just saw now after previous research and sharing my confusion Commented Oct 1 at 16:17

1 Answer 1

Reset to default
1

While I'm aware that the socket -- looking at it as a file with its file permissions -- is either all or nothing (read+write or not, hence the protocol is bidirectional), I was still expecting the wayland idea already enforcing some restrictions by default.

In theory yes. Core Wayland outright doesn't have a protocol that would allow such operations, so access control doesn't even enter the question. For example, screenshots would be implemented as a feature internal to the compositor – you hit a key, the compositor writes out a PNG.

Of course, screen sharing eventually becomes a necessary feature, and compositors add new protocols and interfaces to allow that, usually relying on XDG Portal framework as the "gatekeeper". I'm not sure if GNOME makes serious effort to protect against unconfined apps though – it is sandboxed Flatpak apps (containers) that portals are meant to provide granular access for.

Some compositors deliberately add custom Wayland protocols to allow full access to the screen, e.g. for external screenshot tools, as well as other "risky" things that users expect from X11. I think that's part of the wlroots core that Sway uses. In such cases it's the decision of the compositor to not use any access control.

Improve this answer
2
  • 1
    That explains and clears things up a lot - thanks! But given I'm using sway and therewith wlroots, is there a defined way implementing/enforcing such restrictions? Commented Oct 1 at 19:37
  • I really don't know. I've not used any wlroots based compositor yet. Though my overall impression is that it's not a priority for many of them – rather, their focus is more towards supporting X11-ish workflows (basically the opposite of GNOME's), and even xdg-portal-wlr (the wlroots-specfic backend of the Portal system) seems to be more lenient on sandboxed flatpak/snap apps than e.g. the respective GNOME or KDE ones. Maybe Sway has some access controls in its config, I'm not sure. Commented Oct 3 at 4:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.