[Bug]: input methods that use WAYLAND_SOCKET environment variable regress in 1.15.6

[wengxt]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.15.6

What Linux distribution are you using?

Arch Linux

Linux distribution version

Archlinux

What architecture are you using?

x86_64

How to reproduce

I have an application that may use WAYLAND_SOCKET environment to connect to wayland in certain cases. With WAYLAND_SOCKET, the compositor can identify the client and may expose special wayland object to the client, like granting a certain permission.

Specifically, this is used by weston and kwin to allow input method process to be only forked by compositor.

To reproduce this with weston, install org.fcitx.Fcitx5 from flathub.

Put following content in ~/.config/weston.ini

[core]
xwayland=false

[input-method]
path=/home/user/.local/share/flatpak/exports/bin/org.fcitx.Fcitx5

and start weston (make sure there's no fcitx5 running).

Expected Behavior

fcitx connects to wayland correctly.

Actual Behavior

fcitx quits from weston output saying something about wayland disconnected.

Additional Information

I believe this is relevant to the new wayland security context feature's implementation.

https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-client.c#L1297

wl_display_connect will unset WAYLAND_SOCKET when it's called. The new wayland security context actually calls wl_display_connect and it will effectively unset WAYLAND_SOCKET for the sub process.

WAYLAND_SOCKET should not be used by flatpak for this, because the fd specified by WAYLAND_SOCKET can be only used once.

[smcv]

cc @emersion @swick

I have an application that may use WAYLAND_SOCKET environment to connect to wayland in certain cases. With WAYLAND_SOCKET, the compositor can identify the client and may expose special wayland object to the client, like granting a certain permission.

It sounds as though the compositor is implementing an ad-hoc precursor of the "security context" extension, so that instead of Flatpak giving the app an identifiable socket, the Wayland compositor is giving Flatpak an identifiable socket.

wl_display_connect will unset WAYLAND_SOCKET when it's called

This is unsafe to do in a multi-threaded process: any thread could be calling getenv() concurrently.

[smcv]

It seems odd to me to be using an input method installed as a Flatpak app and giving it special privileges that the rest of the desktop environment - even parts of it that are explicitly in the trusted computing base, like the desktop shell - do not have. Normally, Flatpak apps have fewer privileges than un-sandboxed desktop apps.

In particular, the input method seems like something very "powerful" that needs to be absolutely trusted: it can do anything that you would be able to input with the keyboard.

[swick]

Indeed a bit weird. I was aware that compositors like weston create special privileged sockets and exec apps which then have access to them. For this to be useful all apps must be separated from the trusted computing base the compositor is running in, and flatpak gives you this separation. So, I kind of get the use case here and I think this is a genuine bug.

[wengxt]

It seems odd to me to be using an input method installed as a Flatpak app and giving it special privileges that the rest of the desktop environment - even parts of it that are explicitly in the trusted computing base, like the desktop shell - do not have. Normally, Flatpak apps have fewer privileges than un-sandboxed desktop apps.

In particular, the input method seems like something very "powerful" that needs to be absolutely trusted: it can do anything that you would be able to input with the keyboard.

In the real world, android allows third-party input method from the very beginning, and iOS allows that in some recent versions. I don't think Input method and sandbox really conflicts. I think the "trust" comes from how you install it and set it as input method, not by the fact whether it runs within a sandbox or not.

On other hand, sandbox may help enhance the security (I'm not saying that this is guaranteed today with flatpak though), e.g. preventing other app from accessing the sensitive data that input method saves because input method will use user typing history to adapt to improve user experience.

Right now security context and WAYLAND_SOCKET provides two similar but somewhat different capabilities:

1. WAYLAND_SOCKET can be only used by ONE wayland client.
2. security context is applied to ALL wayland clients in the sandbox.

While there is some conflict with the implementation (listener fd and WAYLAND_SOCKET fd). If we put away the implementation details aside, as today WAYLAND_SOCKET indeed provides something that security context doesn't and I hope at least it can be used with flatpak for now until there's some other alternatives (or maybe extend security context) implemented.

[smcv]

In the real world, android allows third-party input method from the very beginning, and iOS allows that in some recent versions

Yes, and they're very attractive to attackers on those platforms, because a malicious application that says "I'm an input method" is the perfect combination of user-installable and extremely powerful.