[PATCH weston] compositor: Load shell plugin after option modules

[Kristian Høgsberg]

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
> >>values.
> >
> >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
	socketpair(2);
 
> 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...

Kristian