Bug 84817

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?

I say it shul

Sorry about the incomplete comment. I edited the title while drafting one, and hit save. 

As for WAYLAND_SOCKET, if the user needs child processes, that will probably be a bit unusable.


It might also be possible for the setuid helper to setup a bind mount to the socket if it's not possible to make the Wayland server listen on two sockets, but that might be a bit too hackish, as the setuid helper will need to run again when the Wayland server dies to clean up the mounts.

At the very least, if the target user knows the XDG_RUNTIME_DIR and WAYLAND_DISPLAY, you can set permissions for the user on the XDG_RUNTIME_DISPLAY, and WAYLAND_DISPLAY socket file, and then have the user symlink to it in their XDG_RUNTIME_DIR. This requires the user to have execute permissions on the XDG_RUNTIME_DIR. (Either chmod 711, or just grant x permissions with setfacl to the target user). If they know the file names of other files in XDG_RUNTIME_DIR, they will be able to have permissions to them, (mostly 755).

Is someone working on this?

Any known workaround for this?

(In reply to Tapani Pälli from comment #5)
> Any known workaround for this?

sudo -E will cause sudo to leave the whole environment (including XDG_RUNTIME_DIR) intact.

This! They pretend that they care about our security and limit sudo graphical programs but in reality they simply didn't thought about multiuser desktop as a kind. Actually if one really care about security and run every program under specific limited user he will not allowed to do so on wayland. And the only option xhoset +... is actually an advice to make a whole in environment.

(In reply to Paranoik from comment #7)
> This! They pretend that they care about our security and limit sudo
> graphical programs but in reality they simply didn't thought about multiuser
> desktop as a kind. Actually if one really care about security and run every
> program under specific limited user he will not allowed to do so on wayland.
> And the only option xhoset +... is actually an advice to make a whole in
> environment.

It's much more flexible than that. Wayland doesn't do a user lookup at all, or rely on particular authentication files: it relies on filesystem permissions to restrict who can access the socket.

You can grant access to the socket to whichever uid you like, or you can specifically bind-mount the uid into a particular container. So it is more granular, more flexible, but also more secure.

(In reply to Daniel Stone from comment #8)
> You can grant access to the socket to whichever uid you like, or you can
> specifically bind-mount the uid into a particular container. So it is more
> granular, more flexible, but also more secure.

*bind-mount the socket

(In reply to Daniel Stone from comment #8)
> 
> It's much more flexible than that. Wayland doesn't do a user lookup at all,
> or rely on particular authentication files: it relies on filesystem
> permissions to restrict who can access the socket.
> 
> You can grant access to the socket to whichever uid you like, or you can
> specifically bind-mount the uid into a particular container. So it is more
> granular, more flexible, but also more secure.

What is the problem to let everyone access the desktop by default? Why is it blocked? What is this wayland sudo talk is all about? The modern desktop compositor should have been developed with MAC concept in mind. Apps must be isolated and it shouldn't be a security hole to grant programs run under different restricted user accounts to access desktop and interact with the user.

(In reply to Paranoik from comment #10)
> What is the problem to let everyone access the desktop by default? Why is it
> blocked? What is this wayland sudo talk is all about? The modern desktop
> compositor should have been developed with MAC concept in mind. Apps must be
> isolated and it shouldn't be a security hole to grant programs run under
> different restricted user accounts to access desktop and interact with the
> user.

As you say, building in MAC would make the protocol completely different and require everyone to be aware. It would need either SELinux-style explicit labeling, or constant prompts. Instead we chose to make the socket a security boundary, which is still a valid choice.

(In reply to Daniel Stone from comment #11)
> As you say, building in MAC would make the protocol completely different and
> require everyone to be aware. It would need either SELinux-style explicit
> labeling, or constant prompts. Instead we chose to make the socket a
> security boundary, which is still a valid choice.

What prompts? We have a working example, an android. It can run windowed and on the monitor (see samsung dex) and it works just fine. The only thing needed to rethink were: keyboard and mouse events should only be passed to active window, clipboard content should only be seen to a program after user decides to paste its content into the window and of course user level applications shouldn't be able to capture the screen or other application windows client area and create mouse and keyboard events themselves. After that every program running from any user profile can be allowed to access the desktop because no program would be able to steal info from the other program through the desktop or manipulate the other program through its graphical interface. This can absolutely be implemented during the development of a new API. We were told that wayland is a new modern desktop environment made by xorg developers who learned on previous errors. But what we actually see is the same level of security we had before but now programs are banned from appearing on the desktop. No programs no problems. Heh. Its like a joke about a doctor who cured disease by cutting a patient head off. This could be somehow achieved on a previous xorg interface there is no need in new API to ban programs, this is not a new level of security we needed.

(In reply to Paranoik from comment #12)
> The only thing
> needed to rethink were: keyboard and mouse events should only be passed to
> active window, clipboard content should only be seen to a program after user
> decides to paste its content into the window and of course user level
> applications shouldn't be able to capture the screen or other application
> windows client area and create mouse and keyboard events themselves.

All these things are true of Wayland, and have been since day one.

> After
> that every program running from any user profile can be allowed to access
> the desktop because no program would be able to steal info from the other
> program through the desktop or manipulate the other program through its
> graphical interface. This can absolutely be implemented during the
> development of a new API. We were told that wayland is a new modern desktop
> environment made by xorg developers who learned on previous errors. But what
> we actually see is the same level of security we had before but now programs
> are banned from appearing on the desktop. No programs no problems. Heh. Its
> like a joke about a doctor who cured disease by cutting a patient head off.
> This could be somehow achieved on a previous xorg interface there is no need
> in new API to ban programs, this is not a new level of security we needed.

This is unproductive. There is no 'ban' of anything: if you want the socket to be more widely accessible, then you can make it more widely accessible. It's not difficult.

(In reply to Daniel Stone from comment #13)
> All these things are true of Wayland, and have been since day one.
> ...
> if you want the socket
> to be more widely accessible, then you can make it more widely accessible.
> It's not difficult.

So let it be accessible to everyone by default. What this bug and all that sudo arguing are about? If wayland is secure then why the socket is closed and why wayland developers are against sudo'ed programs?

(In reply to Paranoik from comment #14)

On the redhat bugtracker (Bug 1274451) Adam Williamson have told that wayland developers banned root from accessing the desktop because it is insecure and gparted should be rewritten to run GUI from under user and separate it from its core. Others have pointed there that workarounds that let root access desktop introduce a hole in a system. And now you are saying that it is secure from day one. Who is right then?

(In reply to Paranoik from comment #14)
> (In reply to Daniel Stone from comment #13)
> > All these things are true of Wayland, and have been since day one.
> > ...
> > if you want the socket
> > to be more widely accessible, then you can make it more widely accessible.
> > It's not difficult.
> 
> So let it be accessible to everyone by default. What this bug and all that
> sudo arguing are about? If wayland is secure then why the socket is closed
> and why wayland developers are against sudo'ed programs?

Because that isn't the way it works. X11 leans on in-band mechanisms (password-like 'cookies', or UID lookups), and Wayland has none of those mechanisms. The connection is secured by the permissions on the socket. This is a design decision and will not be changed.

(In reply to Paranoik from comment #15)
> On the redhat bugtracker (Bug 1274451) Adam Williamson have told that
> wayland developers banned root from accessing the desktop because it is
> insecure and gparted should be rewritten to run GUI from under user and
> separate it from its core. Others have pointed there that workarounds that
> let root access desktop introduce a hole in a system. And now you are saying
> that it is secure from day one. Who is right then?

root users are not banned from using another user's Wayland socket. No-one is banned from using another user's Wayland socket. If you want to make it accessible to another user, then you can make the socket accessible to them. This is just like running 'xhost' in X11, or sharing your ~/.Xauthority.

I cannot stress this enough: you can run anything you want as any user. No-one is 'banned'. Please stop saying 'root is banned' because it is not true and never has been.

That being said, Adam is right: running large GUI and toolkit apps as root is a terrible idea from a security point of view, and no-one concerned about security ever recommends doing it. But hey, you can do it if you want to.

You're welcome to your own opinion, but you are no longer adding anything of value to this discussion. If you would like to contribute productively, you are welcome to, but this is not it.

(In reply to Daniel Stone from comment #16)

Under banned I mean banned by default. By default root and other users can't access active wayland desktop.

Ok. I've added my restricted users to the same group and now able to run programs under their profiles on wayland display natively. Chrome and firefox weren't ported to wayland yet but in the nearest future they should run under it.

It seems that root is banned explicitly otherwise it will be able to do so already. Millions of users use xhost +si:... as an odd but default step of installation procedure, and it really makes their systems insecure. This caprice to limit Gtk from running under root doesn't make world safer but on contrary led to the very opposite result, but this is the subject of the other bug reports so I am out of here.