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, 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. 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? 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? 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. 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? Maybe the kernel would need a notion of an "app id", orthogonal to PID and UID. Thanks, pq
pgpB8j0sYJjP5.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
