[PATCH wayland 2/2] support specifying custom directories for the client and server

[Pekka Paalanen]

On Wed, 19 Nov 2014 14:14:34 +0100
Marek Chalupa <mchqwerty at gmail.com> wrote:

> Hi,
> 
> maybe I just don't understand how this should work...
> 
> You have system compositor which spawns some other wayland compositors?
> Then you can specify these (or any other) environment vars in the
> compositor, the child compositors will inherit these...
> 
> 
> On 19 November 2014 12:52, Imran Zaman <imran.zaman at gmail.com> wrote:
> 
> > ... corrected jussi email address..
> >
> > BR
> > irman
> >
> > On Wed, Nov 19, 2014 at 12:56 PM, Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> > > On Wed, 15 Oct 2014 17:36:27 +0300
> > > Imran Zaman <imran.zaman at gmail.com> wrote:
> > >
> > >> Hi
> > >>
> > >> support for adjusting socket access rights to allow group of users to
> > >> connect to the socket.
> > >>
> > >> This is used for nested compositor architectures.
> > >> -----
> > >>
> > >> diff --git a/src/wayland-server.c b/src/wayland-server.c
> > >> index ce1eca8..b1ca5e6 100644
> > >> --- a/src/wayland-server.c
> > >> +++ b/src/wayland-server.c
> > >> @@ -39,6 +39,8 @@
> > >>  #include <fcntl.h>
> > >>  #include <sys/file.h>
> > >>  #include <sys/stat.h>
> > >> +#include <sys/types.h>
> > >> +#include <grp.h>
> > >>  #include <ffi.h>
> > >>
> > >>  #include "wayland-private.h"
> > >> @@ -1079,6 +1081,10 @@ wl_socket_init_for_display_name(struct
> > >> wl_socket *s, const char *name)
> > >>  {
> > >>   int name_size;
> > >>   const char *runtime_dir;
> > >> + const char *socket_mode_str;
> > >> + const char *socket_group_str;
> > >> + const struct group *socket_group;
> > >> + unsigned socket_mode;
> > >>
> > >>   runtime_dir = getenv("WAYLAND_SERVER_DIR");
> > >>   if (runtime_dir == NULL)
> > >> @@ -1133,6 +1139,18 @@ _wl_display_add_socket(struct wl_display
> > >> *display, struct wl_socket *s)
> > >>   return -1;
> > >>   }
> > >>
> > >> + socket_group_str = getenv("WAYLAND_SERVER_GROUP");
> > >> + if (socket_group_str != NULL) {
> > >> + socket_group = getgrnam(socket_group_str);
> > >> + if (socket_group != NULL)
> > >> + chown(s->addr.sun_path, -1, socket_group->gr_gid);
> > >> + }
> > >> + socket_mode_str = getenv("WAYLAND_SERVER_MODE");
> > >> + if (socket_mode_str != NULL) {
> > >> + if (sscanf(socket_mode_str, "%o", &socket_mode) > 0)
> > >> + chmod(s->addr.sun_path, socket_mode);
> > >> + }
> > >> +
> > >>   s->source = wl_event_loop_add_fd(display->loop, s->fd,
> > >>   WL_EVENT_READABLE,
> > >>   socket_data, display);
> > >
> > > Hi,
> > >
> > > I'm not sure what to think of these two patches. Are environment
> > > variables WAYLAND_CLIENT_DIR, WAYLAND_SERVER_DIR, and the above really
> > > the right API for this?
> > >
> > > Your system compositor has to be specially written to be a system
> > > compositor and open multiple listening sockets anyway, so I think this
> > > is the wrong way for the server side stuff. For the server side, I
> > > don't think we should have anything of this controlled via environment
> > > variables but new API functions. What those API functions should be is
> > > a good question.
> > >
> > > I believe you don't need any additions in libwayland-server, in fact.
> > > You have very special requirements in how and where to create the
> > > sockets, so you can do that all yourself, up to the point where you have
> > > a socket fd listening for new connections. Then you can use
> > > wl_event_loop_add_fd() (if you even use the libwayland-server event
> > > loops stuff) to monitor the fd. When a client connects, you get a
> > > callback, call accept(), and pass the new fd to wl_client_create().
> > >
> > > Hmm, wait, why am I assuming multiple listening sockets... What is your
> > > architecture here, exactly?
> > >
> > > I have very hard time deciding if we should allow the environment to
> > > overwrite the server and client assumptions on where the socket is. It
> > > would be easier for me to accept new API functions that operate with
> > > absolute paths or existing fds explicitly, but those of course require
> > > both servers and clients to be written to use them.
> > >
> > > Comments, anyone?

Ah ah, sorry, I missed the more recent thread, where similar concerns
were already raised. I'll continue there, if there is any reason to.


Thanks,
pq