BSDs and wl_client_get_credentials

[Simon Ser]

On Monday, January 21, 2019 11:40 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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,

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.