[PATCH 2/2] Support for adjusting socket access rights to allow group of users to connect to the socket.

[Pekka Paalanen]

(Fixing CC lists, please use reply-to-all in the future...)

On Wed, 22 Oct 2014 10:55:25 +0300
Jussi Laako <jussi.laako at linux.intel.com> wrote:

> On 20.10.2014 18:13, Daniel Stone wrote:
> > Each to their own; I don't think it's necessarily any more complex than
> > split compositors, since at some point you have to deal with input
> > splitting anyway, and if you want both security (i.e. random users not
> > opening random devices) and performance (i.e. no unnecessary hops
> > through input compositor for events), you end up having to deal with
> > input splitting in your system compositor anyway.
> 
> Access control is no different whether you have 1 weston or 3 westons 
> running.
> 
> It is about amount of changes needed, fairly small patch vs almost 
> complete weston rewrite...

Yeah, we've had long discussions about this with Imran.

The problem here is doing multi-seat with a single GPU (multi-head), so
for output they need a central compositor.

Running one session compositor per seat, on top of a system compositor,
has some significant advantages:
- each session compositor can be from each user's favourite DE
- there is no need to add restrictions into the shared compositor, like
  preventing pointers or windows from traveling to other users'
  outputs, if you do evdev pass-through
- advertising globals in the protocol can be per-seat, rather than
  every app seeing every seat's output globals

I'm sure there are more, but yes, adding all that isolation into Weston
to share the same compositor instance between all physical seats would
be quite an ordeal. You can't really create, say, multiple
weston_compositor instances, because that means multiple
drm_compositors, which means the GPU sharing part would be hard. And if
you share weston_compositor, then adding the isolation is hard.


Like said, environment variables are not really good here. You can
already, without modifications to libwayland-server, create your custom
sockets like I explained in the earlier thread: just create the socket,
watch the fd in your event loop, accept connections and call
wl_client_create(). You duplicate a bit of code from libwayland-server,
but you have total control on where and how the socket is created, and
you know explicitly from which socket a client comes from.

This would be used by the system compositor to offer sockets for the
session compositors to connect to, right?

When a session compositor is started, you can already use
WAYLAND_SOCKET environment variable to pass an opened connection to it.
If your system compositor forks session compositors, no problem. If
something else starts your session compositors, you need a wrapper
program to pre-create a connection to the socket file in the shared
directory (that is not your XDG_RUNTIME_DIR) and then exec the session
compositor.

Would that solve all the problems you were trying to solve with these
two patches?


Thanks,
pq