[PATCH weston] compositor: Load shell plugin after option modules
hoegsberg at gmail.com
Wed Sep 26 09:26:01 PDT 2012
On Wed, Sep 26, 2012 at 04:24:56PM +0300, Tiago Vignatti wrote:
> On 09/25/2012 06:19 PM, Kristian Høgsberg wrote:
> >On Tue, Sep 25, 2012 at 05:54:40PM +0300, Tiago Vignatti wrote:
> >>BTW (a bit related with this) to solve part of the Bug 53679, the
> >>way we're using socketpair_cloexec to create the client socket and
> >>later get its credentials in wl_client_create is wrong; clients end
> >>up with the same pid, uid, etc as the compositor instead.
> >>Specifically xwayland and weston-desktop-shell are getting the wrong
> >Oh, because we're still holding both ends when we create the client?
> >Hehe, that's wonderful, nice find :) Hmm... do the credentials change
> >after fork or after we close the socket in the parent... I'm not sure
> >how things are supposed to work in that case, should be interesting to
> >find out.
> we discussed this on IRC and it doesn't seem related with who's
> holding any end.
> "returned credentials are those that were in effect at the time of
> the call to connect(2) or socketpair(2)", that's what man 7 socket
> says about the SO_PEERCRED option. So I assume we cannot use it
> after fork, the way we're doing. Man page says also this options is
> specific to use with sockets created via socketpair, which is funny
> cause for us it's working with accept(). But I guess this is okay.
No, it says:
This is only possible for connected AF_UNIX stream sockets and
AF_UNIX stream and datagram socket pairs created using
> Maybe we should special-case the forking clients and get the return
> value from the fork() call, i.e the pid now?
Yeah, I think that's the way to go... I'm just wondering if we should
add a wl_client_set_credentials() or just work around it in weston...
More information about the wayland-devel