BSDs and wl_client_get_credentials

[Pekka Paalanen]

On Sun, 20 Jan 2019 13:51:42 +0000
Simon Ser <contact at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190121/a4500684/attachment.sig>