This makes it impossible for a privileged client to distribute it's
privledges to more than one subprocess, or to both itself and a subprocess.
That is why I would prefer an "id" approach, which I still think would
be a good way for parent processes to send objects to children, even if
it is not used for privileges. If a process has an object it can ask the
server for an "id". It can then use IPC (including environment variables
or argv) and pass the id to any other process. That process can open the
same server, send the id, and get the same object. The id is a random
number generated by the server and it keeps a map of id->object (and
probably throws them away after first use or a timeout).
The already-opened fd is still useful and the top-level privledged
clients would still use this exactly as proposed. If a client tries to
create a screenshooter object and it is not on the privledged socket
then it fails. However any client if it can send the right id can get a
second connection to the screen shooter object. But the only way to get
that id is for a client that has the screen shooter object to ask for it.
The already-opened fd is also useful so all clients don't have to
reproduce whatever rules there are for locating the server. A parent
process using this can be pretty certain that it's child will use the
correct wayland server.
Jason Ekstrand wrote:
On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira <[email protected]
<mailto:[email protected]>> wrote:
Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > Now, the privileged process wants to launch a sub-process. How
will the
> > sub- process connect to the compositor? Remember:
WAYLAND_SOCKET contains
> > a file descriptor number that isn't available to the child process.
>
> Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using
fcntl() to
> set the socket's fd to CLOEXEC?
Setting the socket to O_CLOEXEC is mandatory after you start using
it. Two
processes cannot write to the same streaming socket file descriptor
at the same
time. You might be able to do this with a datagram socket, but
that's not the
case here.
> It is true that multiple process could end up with the same
connection and
> I didn't think about that. The problem is the same if an application
> connects
> to the compositor by itself and then forks. Not sure how the
compositor
> could detect that :s
It can't. It will get very confused because two applications with
independent
states will start stepping on each other's toes. The best outcome of
this
would be if the compositor detected a problem early on and cut the
connection
to both.
The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET
environment variable after getting the file descriptor number and it
must set
O_CLOEXEC. The socket is not available to child processes.
It already does both of these:
http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763
But then the question returns: how do child processes connect to the
compositor, if the environment variable was cleared? How do they
find the
compositor?
Solutions:
1) the compositor MUST have a well-known socket name
=> not an option, since we want to have multiple concurrent
compositors
2) wl_display_connect() doesn't clear the environment, but resets it
to the
actual socket name. It needs to get the socket name from somewhere.
=> problem: if it's getting the name from the compositor, this may
take a
few roundtrips and the process may have decided to start the child
process
3) use a different environment variable. One variable contains the
traditional
socket path and the other contains the file descriptor. The latter
overrides
the former.
This is what we are doing right now. The WAYLAND_DISPLAY environment
variable contains the name of a socket that can be found in
XDG_RUNTIME_DIR. The WAYLAND_SOCKET environment variable (if it exists)
contains a file descriptor that a single client can use to connect to
the compositor. Inside wl_display_connect, we clear WAYLAND_SOCKET but
not WAYLAND_DISPLAY. If both are present, the client connects directly
and is then free to spawn other clients which will connect via
WAYLAND_DISPLAY. However, those other clients will not have the same
priviledged status because they didn't use the direct connection. This
is the way Weston's desktop-shell panel spawns things right now.
4) store both settings in WAYLAND_SOCKET. D-Bus does that:
DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be
attempted in
order.
That's an interesting idea. Not sure what benefit it would have for
Wayland right now though.
Hope that helps,
--Jason Ekstrand
------------------------------------------------------------------------
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
