Re: [PATCH 2/2] proto, server: Add internal server error message. (v2)

2019-01-21 Thread Christopher James Halse Rogers 
On 20 November 2018 8:02:50 pm NZDT, Christopher James Halse Rogers 
 wrote:
>Many languages such as C++ or Rust have an unwinding error-reporting
>mechanism. Code in these languages can (and must!) wrap request
>handling
>callbacks in unwind guards to avoid undefined behaviour.
>
>As a consequence such code will detect internal server errors, but have
>no way to communicate such failures to the client.
>
>This adds a WL_DISPLAY_ERROR_IMPLEMENTATION error to wl_display so that
>such code can notify (and disconnect) clients which hit internal bugs.
>While servers can currently abuse other wl_display errors for the same
>effect, adding an explicit error code allows clients to tell the
>difference between errors which are their fault and errors which are
>the
>server's fault. This is particularly interesting for automated bug
>reporting.
>
>v2: Rename error from "internal" to "implementation", in sympathy with
>X11's BadImplementation error.
>Add more justification in the commit message.
>
>Signed-off-by: Christopher James Halse Rogers
>
>Acked-by: Pekka Paalanen 
>---
> protocol/wayland.xml  |  2 ++
> src/wayland-client.c  |  3 +++
> src/wayland-server-core.h |  4 
> src/wayland-server.c  | 24 +++
> tests/display-test.c  | 40 +++
> 5 files changed, 73 insertions(+)
>
>diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>index 141038b..754b789 100644
>--- a/protocol/wayland.xml
>+++ b/protocol/wayland.xml
>@@ -94,6 +94,8 @@
>summary="method doesn't exist on the specified interface"/>
>   summary="server is out of memory"/>
>+  +   summary="implementation error in compositor"/>
> 
> 
> 
>diff --git a/src/wayland-client.c b/src/wayland-client.c
>index 0ccfc66..b0805f1 100644
>--- a/src/wayland-client.c
>+++ b/src/wayland-client.c
>@@ -185,6 +185,9 @@ display_protocol_error(struct wl_display *display,
>uint32_t code,
>   case WL_DISPLAY_ERROR_NO_MEMORY:
>   err = ENOMEM;
>   break;
>+  case WL_DISPLAY_ERROR_IMPLEMENTATION:
>+  err = EPROTO;
>+  break;
>   default:
>   err = EFAULT;
>   }
>diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
>index 2e725d9..3e0272b 100644
>--- a/src/wayland-server-core.h
>+++ b/src/wayland-server-core.h
>@@ -324,6 +324,10 @@ wl_client_get_object(struct wl_client *client,
>uint32_t id);
> void
> wl_client_post_no_memory(struct wl_client *client);
> 
>+void
>+wl_client_post_implementation_error(struct wl_client *client,
>+const char* msg, ...)
>WL_PRINTF(2,3);
>+
> void
> wl_client_add_resource_created_listener(struct wl_client *client,
> struct wl_listener *listener);
>diff --git a/src/wayland-server.c b/src/wayland-server.c
>index c0ad229..19f6a76 100644
>--- a/src/wayland-server.c
>+++ b/src/wayland-server.c
>@@ -650,6 +650,30 @@ wl_client_post_no_memory(struct wl_client *client)
>  WL_DISPLAY_ERROR_NO_MEMORY, "no memory");
> }
> 
>+/** Report an internal server error
>+ *
>+ * \param client The client object
>+ * \param msg A printf-style format string
>+ * \param ... Format string arguments
>+ *
>+ * Report an unspecified internal implementation error and disconnect
>+ * the client.
>+ *
>+ * \memberof wl_client
>+ */
>+WL_EXPORT void
>+wl_client_post_implementation_error(struct wl_client *client,
>+  char const *msg, ...)
>+{
>+  va_list ap;
>+
>+  va_start(ap, msg);
>+  wl_resource_post_error_vargs(client->display_resource,
>+   WL_DISPLAY_ERROR_IMPLEMENTATION,
>+   msg, ap);
>+  va_end(ap);
>+}
>+
> WL_EXPORT void
> wl_resource_post_no_memory(struct wl_resource *resource)
> {
>diff --git a/tests/display-test.c b/tests/display-test.c
>index 9b49a0e..6d98cc7 100644
>--- a/tests/display-test.c
>+++ b/tests/display-test.c
>@@ -419,6 +419,46 @@ TEST(post_nomem_tst)
>   display_destroy(d);
> }
> 
>+static void
>+post_implementation_error_main(void)
>+{
>+  struct client *c = client_connect();
>+  struct wl_seat *seat = client_get_seat(c);
>+  uint32_t object_id, protocol_error;
>+  const struct wl_interface *interface;
>+
>+  assert(stop_display(c, 1) == -1);
>+  int err = wl_display_get_error(c->wl_display);
>+  fprintf(stderr, "Err is %i\n", err);
>+  assert(err == EPROTO);
>+  protocol_error = wl_display_get_protocol_error(c->wl_display,
>+ &interface,
>+ &object_id);
>+  assert(protocol_error == WL_DISPLAY_ERROR_IMPLEMENTATION);
>+  assert(interface == &wl_display_interface);
>+
>+  wl_proxy_destroy((struct wl_proxy *

Re: Upcoming release

2019-01-21 Thread nerdopolis 
On Friday, January 18, 2019 5:20:40 PM EST Derek Foreman wrote:
> Hi all,
> 
> It's been quite some time since our last weston release, and there's
> been some discussion of getting the next one out in the January to March
> timeframe (this would be the last release to have an autotools build, btw).
> 
> Does anyone have objections to an early February freeze and a March
> release?  Anyone with large series near completion?
> 
> Also, I'd like to float the idea of removing the fbdev backend for this
> release (or the next).  The bulk of the interesting features target the
> drm backend, and it feels like fbdev can sometimes be a bit of a pain to
> update when changes are required elsewhere.  Any strong opinions either way?
> 
> Thanks,
> Derek
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

I feel like the fbdev backend is a good fallback still. Maybe not for Virtual
Box anymore, since there is now a driver for it in Mainline (I haven't tested
it personally though) ...Currently the Framebuffer backend is the only way to
get Weston working on some obscure hardware such as UDL/DisplayLink2 devices.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Simon McVittie 
On Mon, 21 Jan 2019 at 14:40:23 +0200, Pekka Paalanen wrote:
> On Mon, 21 Jan 2019 11:35:12 +
> Simon McVittie  wrote:
> > On Mon, 21 Jan 2019 at 12:40:11 +0200, Pekka Paalanen wrote:
> > > 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?  
> > 
> > Not really. To implement that, you'd need a race-free way to determine what
> > "application" your peer is part of. [...]
>
> That is enlightening. It makes me wonder what people are using
> PID/UID/GID for.

The uid makes a lot of sense *if* you are a security boundary between uids
(like the D-Bus system bus). Is the concept of a Wayland system compositor
still a thing? If it is, then uids are the first/highest level of being able to
distinguish between clients. The next level down is probably the trusted
computing base (TCB: all the trusted OS components, as a monolithic unit) vs.
sandboxed "apps" (Flatpak or Snap or similar), and below that you can start
distinguishing between different "apps".

If your Wayland compositor only serves one user (like GNOME Shell), then
a good use for the uid is "immediately disconnect anyone whose euid is
not me", like the D-Bus session bus does. If you do that, then
tautologously every surviving connection has the same euid, and the only
interesting boundaries are between TCB and "apps", and below that, between
one "app" and another.

Current Linux systems don't really put a useful security boundary between
OS-provided apps in /usr - they can all ptrace each other, they can all induce
each other to execute arbitrary code by overwriting ~/.config or ~/.bashrc or
some other well-known trusted file or by communicating over D-Bus, and so on -
so they're effectively all part of the trusted computing base. Technical users
rely on the fact that these apps all trust each other, too: xterm is an "app",
and so is emacs, but you'd be upset if you found that emacs wasn't allowed to
edit the ~/.bashrc that controls the shell in your xterm, or that your xterm
session isn't allowed to edit the files that are read by emacs.

That's why container-based app systems like Flatpak and LSM-based app systems
like Snap exist: their extra security boundaries give us a way to draw a line
between the TCB (including the compositor, the desktop session's configuration
UI like gnome-control-center, other desktop session bits like dbus-daemon and
gnome-settings-daemon, the terminal and other development tools, etc.), and the
rest of the app world.

I'm writing from the perspective of Linux and GNOME because that's what I use,
but the same is broadly true in all the non-Linux and non-GNOME "freedesktop"
environments, with some relabelling (for instance KDE clearly doesn't have
gnome-control-center, but it presumably has some other UI for global desktop
settings, which has essentially the same requirements as gnome-control-center
in terms of what it needs to be allowed to do).

Non-Linux systems obviously don't have the Linux-specific namespace-based
containers and LSMs, but if BSD users want sandboxed apps that are not in the
TCB, they presumably also have to use either something analogous to a Linux
container (jails?), or some DAC mechanism analogous to an LSM (Capsicum?), to
arrange for the sandboxed app to be prevented from affecting the TCB in ways
that it shouldn't.

Android uses an interesting hack to distinguish between "apps" securely: it
allocates a block of uids for each user account instead of a single uid,
allocates one uid per user account per "app", and runs each "app" under its
appropriate uid. This is not straightforward to retrofit onto an existing
ecosystem like the Unix/X11/Wayland/freedesktop stack, though: it only works
because Android is its own independent ecosystem from a UI and app development
point of view.

smcv
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Pekka Paalanen 
On Mon, 21 Jan 2019 11:52:46 +
Simon Ser  wrote:

> On Monday, January 21, 2019 11:40 AM, Pekka Paalanen  
> wrote:
> > On Sun, 20 Jan 2019 13:51:42 +
> > Simon Ser  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


pgpX31S9P2M0v.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Simon Ser 
On Monday, January 21, 2019 1:40 PM, Pekka Paalanen  wrote:
> That is enlightening. It makes me wonder what people are using
> PID/UID/GID for.

Yeah. Maybe we should add some big warning signs "even if you think it's safe,
it isn't, don't use this for security" in wl_client_get_credentials docs.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Pekka Paalanen 
On Mon, 21 Jan 2019 11:35:12 +
Simon McVittie  wrote:

> On Mon, 21 Jan 2019 at 12:40:11 +0200, Pekka Paalanen wrote:
> > 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.  
> 
> D-Bus uses (and needs) similar functionality, so if you learn from
> what D-Bus did, you can fast-forward past a lot of tedious portability
> discussions that we already had.

Hi Simon,

that is an excellent idea, thank you.


> > But could we make it return obviously invalid values?  
> 
> libdbus uses (pid_t) -1, (uid_t) -1 and (gid_t) -1 as the obviously-invalid
> values. On POSIX systems, the -1 values for uid_t and gid_t are not suitable
> for normal use due to their special meaning in setreuid() and setregid(), and
> negative PIDs are not suitable for normal use due to their special meaning in
> kill(), so that seems safe.

Hmm, -1 pid might actually be unsafe, if people don't expect that it
could be returned and may pass it to kill() to forcefully destroy a
client process. Seems there is no safe invalid value for pid wrt.
kill(), other than compositor's own pid which callers are expected to
filter out already.


> > 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?  
> 
> Not really. To implement that, you'd need a race-free way to determine what
> "application" your peer is part of. The security boundary between unconfined
> processes with the same uid is sufficiently nonexistent that this is unlikely
> to be viable without using LSMs (like Snap's use of AppArmor) and/or 
> containers
> (like Flatpak's use of various namespaces).
> 
> Note that deriving information from the pid is easy to defeat if you have
> access to a mechanism like setuid or filesystem capabilities, which
> escalates capabilities while preserving the pid.
> See .
> It can also be defeated by pid reuse, although that's a harder attack.
> 
> In Linux, SO_PEERCGROUP has been proposed but not accepted; if that
> existed then you'd be able to tell which cgroup the peer was in, for
> example on systemd systems.
> 
> On systems with LSMs (SELinux, AppArmor, etc.) you can use SO_PEERSEC
> to get the peer's LSM label, which is useful if your app framework uses
> LSMs (for example Snap does, but only on systems booted with AppArmor
> enabled).
> 
> Flatpak uses /proc/$pid/root/.flatpak-info as a roundabout way to discover
> which mount namespace the peer is in, which is not *perfectly* race-free
> (it can be defeated by pid reuse) but is believed to be good enough. It
> helps that Flatpak's D-Bus proxy is not under the control of the app,
> so it's hard (hopefully impossible?) to induce it to exit at just the
> right moment.
> 
> The D-Bus Containers1 interface (which I'm slowly working on as a replacement
> for Flatpak's D-Bus proxy) uses a separate listening socket per
> (app-)container, and requires the container framework to ensure that the
> confined app can't connect to the "global" D-Bus socket (as Flatpak already
> does).

That is enlightening. It makes me wonder what people are using
PID/UID/GID for.


Thanks,
pq


pgpO9NUV8xMgD.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Simon Ser 
On Monday, January 21, 2019 12:35 PM, Simon McVittie  wrote:
> Note that deriving information from the pid is easy to defeat if you have
> access to a mechanism like setuid or filesystem capabilities, which
> escalates capabilities while preserving the pid.
> See .

Hmm, I see.

> It can also be defeated by pid reuse, although that's a harder attack.

Ah, I see. So the idea is:

1. Open a connection from PID x
2. Fork, make PID x exit
3. Make another binary use PID x

Indeed, it now seems like using this for security is a very bad idea. Let's
just forget about this, then. Thanks for the explanation!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

2019-01-21 Thread Pekka Paalanen 
On Fri, 18 Jan 2019 09:05:53 +0530
"Sharma, Shashank"  wrote:

> On 1/17/2019 5:33 PM, Pekka Paalanen wrote:
> > On Wed, 16 Jan 2019 09:25:06 +0530
> > "Sharma, Shashank"  wrote:
> >  
> >> On 1/14/2019 6:51 PM, Pekka Paalanen wrote:  
> >>> On Thu, 10 Jan 2019 20:32:18 +0530
> >>> "Sharma, Shashank"  wrote:
> >>>  
>  Hello All,
> 
>  This mail is to propose a design for enabling HDR support in
>  Wayland/Weston stack, using display engine capabilities, and get more
>  feedback and input from community.  

> > In summary, rather than dynamically allow or not allow, a compositor
> > needs to live by its promise on what works. It cannot pull the rug from
> > under a client by suddenly hiding the window or showing it corrupted.
> > That is the baseline in behaviour.  
> Makes a lot of sense, and sounds like a stable design too.
> As per this design policy, while coming up, compositor can analyze the 
> static environment conditions like:
> - HW support for HDR
> - Kernel support for HDR
> 
> and based on these two it can decide to advertise the HDR capabilities 
> via the protocol, and once it does so, it has to make sure that it lives 
> up-to expectation.
> Now, the only variable in the environment is a hot-pluggable monitor, 
> which might/might not support HDR playback, and that needs to be handled 
> at runtime by:
> - Doing H2S tone mapping, if monitor can't support HDR playback.
> - and REC2020->REC709 conversion using CSC.
> - using GL blending as fallback if we are not able to prepare a plane 
> only state.
> 
> Does it seem like correct interpretation of your suggestions ?

Yes, it does.

Mind, in the future Weston may very well also support GPU hotplug for
additional sinks, which means that the kernel and graphics card support
becomes variable as well. But handling that is no different from
handling monitor variability.

> > Then we can have some mechanisms in place to inform clients about
> > changed conditions, like sending HDR content becomes useful or stops
> > being useful. The first mechanism here is the wl_surface.enter/leave
> > events: if the wl_surface enters the first HDR output, or leaves the
> > last HDR output, the client will know and may adapt if it wants to.  
> Again, sounds like a good idea.

As discussed with Graeme, the mechanism here might well be the
"prioritised output" protocol yet to be invented.


> > This means that you need to avoid interface name conflicts between
> > weston and wayland-protocols extensions.  
> Got it, I think you are suggesting something like the way how we 
> implemented aspect-ratio protocol in weston.

Well, aspect ratio did not have any protocol in the end. :-)


Thanks,
pq


pgp9qrDzyR38P.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

2019-01-21 Thread Pekka Paalanen 
On Fri, 18 Jan 2019 19:02:01 +1100
Graeme Gill  wrote:

> Pekka Paalanen wrote:
> 
> Hi,
> 
> > If a wl_surface straddles multiple outputs simultaneously, then
> > wl_surface.enter/leave events indicate the surface being on all those
> > outputs at the same time. The client is expected to take all the
> > entered outputs into consideration when it chooses how to render its
> > image. For HiDPI, this usually means taking the maximum output scale
> > from that set of outputs. The compositor will then automatically
> > (down)scale for the other outputs accordingly.  
> 
> right, I was guessing this is how it works. So an obvious heuristic
> for HiDPI is to render to the highest density output, on the basis
> that the compositor down-sampling is the least detrimental to quality.
> 
> A wrinkle in using the same idea for Color Management is that such
> a heuristic may not be as clear. For the case of a window being moved from
> one output to another, then either a last to leave or first to enter
> might make sense. If (as I presume) surfaces are multiply mapped
> to achieve mirroring or similar (picture in picture ?), then I'm not so
> sure how the most important display can be determined heuristically.
> Even in the case of a projector, I could imagine under some circumstances
> the projected color accuracy is secondary, and other circumstances it is
> most important.

Hi Graeme,

yes, this is a good concern. I think we might be needing an extension
to tell the client which output to prioritise for. We already have an
analogue of that in the Presentation-time extension: a wl_surface's
timings can only be synchronised to one output at a time, so the
presentation feedback events tell the client which output it was
synchronised to on each frame.

I cannot imagine a case where the output for timings and the output for
color would be different, but I also probably would not re-use the
Presentation-time extension here. Instead, we would probably need to
handle it in the color related extensions explicitly.

> > Yes and no. Yes, we do and should let clients know what kind of outputs
> > their contents will be shown on. However, we will in any case need the
> > compositor to be able to do the full and correct conversion from what
> > ever the client has submitted to what is correct for a specific output,
> > because nothing guarantees that those two would always match.  
> 
> I don't think that's technically possible, because it's analogous to
> Wayland taking on the rendering.

Your explanation further below is very enlightening on what "rendering"
is.

> But I also don't think it's a necessary
> either, because as long as the client can do it's rendering for the
> output that is most quality sensitive, then it's enough that the compositor
> can do a less perfect transform between the display or colorspace that was
> rendered to and the display it is actually appearing on. This is a much 
> simpler
> proposition than full general color management since you can assume that
> all buffers are display-like and only have 3 channels, and that simple
> to define color transform intents will be sufficient. Similarly to the HiDPI
> case, the visual quality may jump slightly if the surface is re-rendered
> for its actual output, but on most displays the difference shouldn't terribly
> obvious unless you were looking for it.

Yes, I think we found the same page here. :-)

> Some nice properties of this approach are that it provides the usual
> mechanism for an application (like a Color Management profiling app.)
> to set device values using the null transform trick (setting source
> colorspace the same as destination. If the two profiles are the same,
> color conversion should be skipped by the CMM/compositor.)
> A second property is that it would be possible to set a default
> source colorspace for clients that don't know about color management
> (i.e. sRGB). This allows a "color managed desktop" using existing window
> managers and applications, solving the problems of using wide gamut or HDR
> displays running in their full mode.

Yes, indeed.

> > I'm not sure I understand what you mean. Above you seemed to agree with
> > this. Maybe I should emphasise the "if it has to"? That is, when for
> > whatever reason, the client provided content is not directly suitable
> > for the output it will be displayed on.  
> 
> OK, a detail I seem to be having difficulty conveying is the
> difference between doing a bulk conversion between two colorspaces,
> and rendering in a color aware fashion. Example :- consider rendering
> a document stored in a sophisticated page description language
> such as PDF, PS or XPF. These are color aware formats, and in general
> pages may be composed of multiple different graphic elements that can
> have their color described in a multitude of different ways. Some may
> be in device dependent spaces such as RGB. Some may be in CMYK.
> Some may be in device independent CIE based spaces such as L*a*b*.
> So

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Simon Ser 
On Monday, January 21, 2019 11:40 AM, Pekka Paalanen  
wrote:
> On Sun, 20 Jan 2019 13:51:42 +
> Simon Ser  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

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Simon McVittie 
On Mon, 21 Jan 2019 at 12:40:11 +0200, Pekka Paalanen wrote:
> 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.

D-Bus uses (and needs) similar functionality, so if you learn from
what D-Bus did, you can fast-forward past a lot of tedious portability
discussions that we already had.

There are basically two kernel API families that do this sort of thing:

* A socket option or function for the server to query the client's
  credentials without the client's help. This is GLib
  g_socket_get_credentials(). Known implementations in libdbus
  (GLib supports most of these, but I think not all of them):

  - Linux SO_PEERCRED
  - OpenBSD SO_PEERCRED (like Linux but with a different struct name)
  - NetBSD LOCAL_PEEREID (like Linux and OpenBSD but with different naming)
  - Solaris getpeerucred()
  - getpeereid() (available on multiple OSs but doesn't tell you the pid)

* A socket option or function for the client to send credentials attached
  to a message, which the server can trust to have been validated by the
  kernel. This is GLib's higher-level g_unix_connection_send_credentials() and
  g_unix_connection_receive_credentials(), or lower-level
  GUnixCredentialsMessage. There's only one implementation in libdbus,
  which I think is also in GLib:

  - FreeBSD/DragonflyBSD SOL_SOCKET/SCM_CREDS

See libdbus dbus/dbus-sysdeps-unix.c or GLib gio/gsocket.c,
gio/gunixconnection.c, gio/gunixcredentialsmessage.c for reasonably portable
versions of both of those, and in particular a good amount of the research for
which OSs support which APIs.

I think it's reasonable for SO_PEERCRED, LOCAL_PEEREID etc. to be combined into
one portable abstraction (as long as it has a way to say "unknown" for each
field, to account for protocols that give a superset or subset of what Linux
does) but I agree that SCM_CREDENTIALS makes more sense as a separate
abstraction. With hindsight, GLib gets this right where libdbus didn't.

Linux also has SO_PEERGROUPS which returns the supplementary groups (as
far as I know it is not documented whether the primary group is included,
so you have to get the primary group from SO_PEERCRED and combine the two).
libdbus is careful to distinguish between "we know the primary group is 42
and there might be other groups" (on older Linux or non-Linux, when
SO_PEERGROUPS didn't work) and "we know the process has exactly one group,
and it is 42" (on recent Linux, when SO_PEERGROUPS did work). In
application-level API we only expose group information in the SO_PEERGROUPS
case, where we can guarantee that we have the full list.

> But could we make it return obviously invalid values?

libdbus uses (pid_t) -1, (uid_t) -1 and (gid_t) -1 as the obviously-invalid
values. On POSIX systems, the -1 values for uid_t and gid_t are not suitable
for normal use due to their special meaning in setreuid() and setregid(), and
negative PIDs are not suitable for normal use due to their special meaning in
kill(), so that seems safe.

> 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 it does, on at least some OSs. That's why the D-Bus wire protocol starts
with a single '\0', before the (ASCII) SASL handshake: on OSs that use
SCM_CREDENTIALS, the \0 has the credentials attached to it.

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

Not really. To implement that, you'd need a race-free way to determine what
"application" your peer is part of. The security boundary between unconfined
processes with the same uid is sufficiently nonexistent that this is unlikely
to be viable without using LSMs (like Snap's use of AppArmor) and/or containers
(like Flatpak's use of various namespaces).

Note that deriving information from the pid is easy to defeat if you have
access to a mechanism like setuid or filesystem capabilities, which
escalates capabilities while preserving the pid.
See .
It can also be defeated by pid reuse, although that's a harder attack.

In Linux, SO_PEERCGROUP has been proposed but not accepted; if that
existed then you'd be able to tell which cgroup the peer was in, for
example on systemd systems.

On systems with LSMs (SELinux, AppArmor, etc.) you can use SO_PEERSEC
to get the peer's LSM label, which is useful if your app framework uses
LSMs (for example Snap does, but only on systems booted with AppArmor
enabled).

Flatpak

Re: BSDs and wl_client_get_credentials

2019-01-21 Thread Pekka Paalanen 
On Sun, 20 Jan 2019 13:51:42 +
Simon Ser  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