wayland multi-user

solskog · 2022-01-16 00:59:56

echo $UID
1000
chmod o=x $XDG_RUNTIME_DIR
chmod o=rwx ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}

From now on every user on this system can share the same login users WAYLAND_DISPLAY.
Is this safe?

Trilby · 2022-01-16 01:29:28

Safe from what? For what? And why would you want to do this?

What other "users" are there? Are these other people at other seats on the same machine, or just other user accounts?

Wayland is designed to handle multi-seat well: there can be multiple people on the same machine with different seat sessions on the same wayland server connection (each user has their own keyboard, monitor(s), cursor, selections, etc). However, I'm not sure how extensively any major compositors actually implement these multi-seat capabilities.

solskog · 2022-01-16 03:20:51

Let me start with multi-user-accounts. I wants to create an environment with user space separation in one login session, means different user accounts starts different applications but shares one and the same display server in the same login session. Here is how it looks like in Xorg.

$ setsid --fork /bin/st

|-login(302)---startx(420,loginuser)---xinit(554)-+-dwm(565)-+-bash(3745)              
|                                                                     |
|                                                                     -Xorg(555)-+-{Xorg}(556)
|                                                                                |-{Xorg}(562)
|                                                                                 -{Xorg}(563)
|-st(655,admin)---bash(656)---vi(25824)
                              `-pstree(28310)

Where you can see the login user and st's (suckless terminal) owner (admin) are different and this can be achieved with shared XAUTHORITY in Xorg.

I did the same in wayland by sharing the ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}.

$ setsid --fork /bin/firefox
systemd(1)-+-GeckoMain(10875,firefoxuser)-+-Socket Process(10924)-+-{Socket Process}(10932)
           |                      |                       |-{Socket Process}(10933)
           |                      |                       |-{Socket Process}(10934)
           |                      |                       `-{Socket Process}(10937)
           |-login(562)---river(610,loginuser)-+-rivertile(649)
           |                                                  |-{river}(626)

Where firefox detaches from login user.
The Goal of user space separation is to prevent malicious GUI application gain access to filesystem resources. e.g the owner of ST has right to access NFS but loginuser and firefoxuser don't.
IF wayland is considered "safe to handle multi-seat", it should also be safe for this multi-user-account scenario as well isn't it? I don't kown how to setup an multi-seat environment and if it requires different ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY} for each seat or it's shared as I did?

Last edited by solskog (2022-01-16 03:34:54)

pptp · 2022-03-23 09:56:20

Hi there, hope I'm not hijacking the thread.
I'm in a similar situation, using river as well.
In my case I'd run Zoom app as other user.

So one question is whether sharing x to my XDG_RUNTIME_DIR and rwx to WAYLAND_DISPLAY with other user,
which is also suggested in Gentoo wiki, see https://wiki.gentoo.org/wiki/Wayland#Ru … erent_user ,
is much different (security- and privacy-wise) form logging in at a different tty as other user and launch river and Zoom from there
(with its own XDG_RUNTIME_DIR and WAYLAND_DISPLAY).
For example, can Zoom log keystrokes or spy on windows from my user, in first scenario?

Trilby · 2022-03-23 12:41:22

pptp wrote:

For example, can Zoom log keystrokes or spy on windows from my user, in first scenario?

This is not a "wayland" question, it is a compositor (river?) question as this is entirely up to the compositor and what protocols it implements. However, even in cases where a given compositor might imlpement a way that such information could be retrieved, there are few notable shared protocols for this - so a malicious program (e.g., which you suspect Zoom of being) could not be written to "log keystrokes on wayland", it would have to be written to "log keystrokes on weston" or "log keystrokes on river" or separately for each and every compositor implementation that allowed for it.

I don't think river exposes such a protocol. Somewhat ironically, weston might (it implements some very questionable protocols).

Last edited by Trilby (2022-03-23 12:45:20)

pptp · 2022-04-01 14:45:41

Thanks, that makes sense.
I think both OP and I are using river as compositor.

Mostly as a reference for myself, what I'm doing:

setfacl -m user22:r-x -- /run/user/1000
setfacl -m user22:rwx -- /run/user/1000/wayland-1
setfacl -m user22:rw -- /run/user/1000/wayland-1.lock
su --login --whitelist-environment=WAYLAND_DISPLAY,XDG_RUNTIME_DIR user22

I guess it would work similarly if I used LXC.

Trilby · 2022-04-01 16:03:51

FYI, you can also very easily run nested compositor sessions which would likely be better for achieving the goals as I understand them. So you can launch river as a different user from within river running as the primary user. (though using 'cage' as the nested compositor might make more sense).

Last edited by Trilby (2022-04-01 16:04:15)

pptp · 2022-04-04 13:49:11

I see. If I try to run nested river, without giving the 2nd user access to my wayland socket, then

info: initializing server
info(wlroots): [backend/x11/backend.c:397] Creating X11 backend
Invalid MIT-MAGIC-COOKIE-1 keyerror(wlroots): [backend/x11/backend.c:410] Failed to open xcb connection
error: BackendCreateFailed

Haven't tried to compile it (or cage) without xwayland support yet.

Trilby · 2022-04-04 14:24:03

That's not a wayland issue, it's an X11 issue likely due to the user you are attempting to run as not having a r/w-able .Xauthority or similar. Disabling Xwayland would avoid the issue - but if you want xwayland for the nested user you'd need to fix the issue instead. But you'd run into the same problem if you tried to run anything requiring xwayland under the secondary user in your other approaches too.

Last edited by Trilby (2022-04-04 14:25:22)

Arch Linux

#1 2022-01-16 00:59:56

wayland multi-user

#2 2022-01-16 01:29:28

Re: wayland multi-user

#3 2022-01-16 03:20:51

Re: wayland multi-user

#4 2022-03-23 09:56:20

Re: wayland multi-user

#5 2022-03-23 12:41:22

Re: wayland multi-user

#6 2022-04-01 14:45:41

Re: wayland multi-user

#7 2022-04-01 16:03:51

Re: wayland multi-user

#8 2022-04-04 13:49:11

Re: wayland multi-user

#9 2022-04-04 14:24:03

Re: wayland multi-user

Board footer