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

[Pekka Paalanen]

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?


Thanks,
pq