On Monday, January 21, 2019 11:40 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Sun, 20 Jan 2019 13:51:42 +0000 > Simon Ser <cont...@emersion.fr> wrote: > > > Hi, > > > > I wanted to start discussing about wl_client_get_credentials support in > > various BSDs. wl_client_get_credentials uses getsockopt() with > > SO_PEERCRED, which isn't supported on BSD. On the other hand, using > > SCM_CREDENTIALS by passing a `struct ucred` ancillary message is > > supported on both Linux and BSD [1]. > > > > Would it be possible to use this mechanism instead of SO_PEERCRED in > > wl_client_get_credentials? Should we use SCM_CREDENTIALS on all > > platforms or just BSDs? Any thoughts on doing this in a > > backwards-compatible way? > > > > Thanks, > > > > [1]: > > https://www.freebsd.org/cgi/man.cgi?query=unix&sektion=7&apropos=0&manpath=SuSE+Linux%2fi386+11.3 > > Hi Simon,
Thanks for your reply! > I don't think we can fix wl_client_get_credentials(), the semantics are > very explicitly tied to the SO_PEERCRED behaviour. What I think we > should do instead is to look into making a new API using > SCM_CREDENTIALS. Are you worried about API stability? Would it be reasonable to keep using SO_PEERCRED on Linux but to use SCM_CREDS on BSDs? > wl_client_get_credentials() does not always work, but the only > non-working case documented is returning the compositor's own PID etc. > On operating systems where SO_PEERCRED does not exist, we cannot simply > hardcode the function to return the compositor's own PID, because > someone might be using that to identify clients that got their Wayland > connection pre-created with socketpair() (regardless of whether that is > a good idea or not). But could we make it return obviously invalid > values? BSDs currently return a zero PID. Maybe we should document this? > As for new API, we could have wl_client_get_scm_credentials() or > something, and automate the sending and receiving of SCM_CREDENTIALS at > the first message to go through the Wayland connection. Does > SCM_CREDENTIALS require at least one byte of actual data like > SCM_RIGHTS does? Yes, at least one byte of data is required on Linux. I'm not sure this is the case on BSDs. > But, is automating a good thing, or would people want to be able to > choose which credentials they will be sending and when? If people want > to control that, then the server-side API needs to have a notification > for received credentials. Hmm. Maybe this could be a new data-type, just like FDs. But this would make it difficult to use for filtering Wayland globals. I'm not sure there's a use-case for choosing credentials. Only PID 1 is allowed to fake credentials IIRC. > Currently I have no clear opinion on what might be best. PID, UID and > GID are quite poor for authorization anyway, I wish we could identify > some more... fine-grained? At the application level? But is there even > a useful definition of "an application" from the kernel point of view? PIDs are enough for our use-case. We just need to get the client's executable filepath to decide whether or not it has access to a global. I'm not sure there's a better way. The only other way we could think of would be to always make the compositor spawn all clients, just like Flatpak. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel