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

[Imran Zaman]

... 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?
>
>
> Thanks,
> pq