<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Allowing a second user running on a WAYLAND_DISPLAY requires the second user to have full permissions to XDG_RUNTIME_DIR"
href="https://bugs.freedesktop.org/show_bug.cgi?id=84817#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Allowing a second user running on a WAYLAND_DISPLAY requires the second user to have full permissions to XDG_RUNTIME_DIR"
href="https://bugs.freedesktop.org/show_bug.cgi?id=84817">bug 84817</a>
from <span class="vcard"><a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> <span class="fn">Pekka Paalanen</span></a>
</span></b>
<pre>If the main goal of this bug is to allow chosen other users to access one
user's Wayland session compositor, another option could be allowing the
compositor to create a socket in the other user's XDG_RUNTIME_DIR. That would
be fairly equivalent to setting up Xauthority for the other user on X11. The
problem with that is allowing the session compositor to create the socket file.
Letting other users use this user's XDG_RUNTIME_DIR is problematic, because the
other users may consume the disk space from XDG_RUNTIME_DIR. Also, you should
not have the other user set XDG_RUNTIME_DIR to this user's directory, because
then all the things in XDG_RUNTIME_DIR would be mixed up.
At a first glance, it seems to me that there is no simple solution.
Maybe one solution would be a sudo-like wrapper, or maybe an enhancement in
sudo, that would first open a connection to the session compositor, then switch
user, and finally launch the app with WAYLAND_SOCKET instead of
WAYLAND_DISPLAY. Granted, it would be quite limited in operation, as you could
not e.g. open a terminal with the wrapper and then just launch more apps. OTOH,
that would also make it more secure, FWIW.
An ssh-X11-forwarding-like helper tool might work too: leave a "service"
process running as the current user that will connect to the session compositor
as requested, fork another process at the other user that sets up a
WAYLAND_DISPLAY and a socket file in the other user's XDG_RUNTIME_DIR. When the
other process receives a Wayland connection attempt, it communicates with the
"service" to open a real connection, and somehow forwards the connections.
Making modifications to shm buffer allocation are IMO a separate issue, than
allowing one user to access another user's display server. I'd say that is out
of focus in this bug.
Should we rename this bug to allow running Wayland apps as another local user
in general?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>