BSDs and wl_client_get_credentials

[Pekka Paalanen]

On Mon, 21 Jan 2019 11:52:46 +0000
Simon Ser <contact at emersion.fr> wrote:

> 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?

Yes, SO_PEERCRED and SCM_CREDENTIALS produce different things. We
cannot trust the client side implementation using SCM_CREDENTIALS is
what we wrote in libwayland-client, so the subtle difference might
raise awkward problems that are hard to foresee.

Or is SCM_CREDS different from SCM_CREDENTIALS?

I suppose we need to weight the below issue with kill(pid < 1) against
using SCM_CREDENTIALS instead?

> > 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?

If unmodified upstream libwayland does that, then yes, it would be good
to document.

However, the worst case expectation is that compositors will only check
the returned pid against their own, and if it doesn't match, may call
kill() etc. on it. kill(0) has special meaning, at least in Linux.


> > 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.

Faking is one thing, but I referred to all the alternatives one is
allowed to use according to unix(7) even without privileges.

> > 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 suppose access to Wayland globals is not that dangerous that it would
need to be secured against the races that make PID unreliable?

> 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.

See McVittie's answer. I agree it would be nice to have something
better. Maybe LSM labels would be good. libwayland-server already has
wl_client_get_fd() which can be used to fetch LSM labels.


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/cf10b553/attachment.sig>