Re: Proxying Wayland for security

On Wed, 28 Jul 2021 at 18:22:55 +0100, Carsten Haitzler wrote: > but in the end almost everyone wants some way to differentiate what clients > can > and cannot do based on some kind of sandboxing and rules. Before that can happen, you need a concept of identity: you can't say anything about what

Re: Chrome Remote Desktop and Wayland

On Tue, 21 Apr 2020 at 14:21:39 +0200, Benjamin Berg wrote: > Yes, I agree that "user" is very similar. However, it cannot currently > convey any information about whether a graphical session is already > running or whether it is capable of spanning multiple logind sessions. FWIW, the session bus

Re: Chrome Remote Desktop and Wayland

On Wed, 08 Apr 2020 at 11:02:36 +0200, Jonas Ådahl wrote: > With that being said, it is possible to run multiple D-Bus sessions, > where session busses are separate - it's just that noone actually does > it as even if you have separate D-Bus sessions, separate > $XDG_RUNTIME_DIRs, the sessions

Re: XDG_RUNTIME_DIR on a system with no "logins"

On Wed, 18 Dec 2019 at 13:10:14 +0100, Guillermo Rodriguez wrote: > > > >But how is this done for a system where normally no users "log in", > > > >e.g. a fixed-function embedded system with a graphical user interface? Decide what "logging in" means for you, and make it work like that. Imagine

Re: Using libweston with GTK/GDK

On Mon, 03 Jun 2019 at 14:17:21 +0300, Pekka Paalanen wrote: > For > a test suite, you could use an environment variable to override the > default search path, but for a manual launch that is a bit more > inconvenient. This is the solution that is generally recommended in the GLib/GTK/GNOME stack

Re: xwayland display variable

On Wed, 01 May 2019 at 14:30:52 +0300, Damian Ivanov wrote: > export WAYLAND_DISPLAY=wayland-1 > GDK_BACKEND=x11 gedit //starts on wayland-0 If you are using GDK_BACKEND=x11, then gedit is not acting as a native Wayland app, so it will not look at WAYLAND_DISPLAY. Instead, it will be acting as an

Re: BSDs and wl_client_get_credentials

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 >

Re: BSDs and wl_client_get_credentials

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

Re: Session suspension and restoration protocol

On Wed, 20 Jun 2018 at 21:26:26 +0200, Roman Gilg wrote: > On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie wrote: > > When we discussed this on #gnome-hackers we were talking about doing > > restoration by passing the restored session ID as platform_data to the > > Ac

Re: Session suspension and restoration protocol

On Tue, 19 Jun 2018 at 16:21:14 +0200, Michel Dänzer wrote: > On 2018-06-19 02:22 PM, Simon McVittie wrote: > > This indirect launching also avoids doing a fork-and-exec in the > > compositor or session manager, which can be problematic under low-memory > > conditions: the ker

Re: Session suspension and restoration protocol

On Tue, 19 Jun 2018 at 13:56:22 +0200, Markus Ongyerth wrote: > P.S. I just thought about this ab it more, and something else came to my mind: > How is env passed with dbus activation? afaik the session bus does not run in > under the compositor, so if we aren't on wayland-0 (which can happen

Re: Session suspension and restoration protocol

On Tue, 19 Jun 2018 at 11:18:17 +0200, Markus Ongyerth wrote: > On 2018/6月/18 05:05, Roman Gilg wrote: > > * using D-Bus interface only to secure against sandboxed clients > What? Why exactly? When I first read this, I expected that the client is > supposed to use the portal stuff to call out of

Re: Session suspension and restoration protocol

This document might be useful for the D-Bus side: https://dbus.freedesktop.org/doc/dbus-api-design.html On Mon, 18 Jun 2018 at 17:05:25 +0200, Roman Gilg wrote: > In certain high levels the compositor will ask the client through a > special D-Bus interface to restore its internal

Re: [PATCH weston 2/2] Add .gitlab-ci.yml

On Wed, 06 Jun 2018 at 15:33:13 +0100, Emil Velikov wrote: > On 5 June 2018 at 23:06, Daniel Stone wrote: > > + - apt-get -y --no-install-recommends install build-essential automake > > autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev > > libpixman-1-dev libpng-dev libjpeg-dev

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On Thu, 22 Mar 2018 at 08:22:23 -0400, Simon Ser wrote: > I think we really do mean "decorations" and not "window management". > Decorations > are used for window management, but their scope is larger - they are also user > interface components. > > For instance, I can think of GNOME [1] and

Re: [PATCH wayland 1/2] wayland-egl-symbols-check: add ARM specific glib entrypoints

On Tue, 20 Mar 2018 at 11:10:44 +, Emil Velikov wrote: > Subject: [PATCH wayland 1/2] wayland-egl-symbols-check: add ARM specific > glib entrypoints ARM-specific *glibc* entry points, GLib has nothing to do with this :-) smcv ___ wayland-devel

Re: [PATCH wayland 2/2] wayland-egl: Make symbol test fail on failure

On Mon, 19 Mar 2018 at 13:39:30 +, Daniel Stone wrote: > On 19 March 2018 at 13:27, Emil Velikov wrote: > >> I'd not realised AC_PROG_NM didn't set a full path. Brilliant. Maybe > >> replace test -x "$NM" with $NM -V >/dev/null 2>&1? Or just trusting it > >> works if

Re: [PATCH weston 1/2] weston: remove SEGV and ABRT handlers

On Wed, 07 Feb 2018 at 15:12:48 +0200, Pekka Paalanen wrote: > Weston handles all other signals via signalfd(), these were the only ones > that used the signal()/sigaction() kind of API. That's good. The traditional pipe-to-self is basically an implementation of signalfd() for kernels that don't

Re: [PATCH weston 1/2] weston: remove SEGV and ABRT handlers

On Wed, 07 Feb 2018 at 12:51:14 +0200, Pekka Paalanen wrote: > Catching an ABRT is kind of ok, catching a SEGV is russian roulette. We > have been quite lucky with it, but I've started hitting crashes inside > malloc() which causes a deadlock when our SEGV handler needs to malloc() > as well

Re: Weston stuff: fractional HiDPI, FreeBSD, Rust

On Thu, 18 Jan 2018 at 18:25:02 +, Daniel Stone wrote: > I do have another suggestion though: can you please change the platform > checks (#ifdef __linux__ and #ifdef FreeBSD) to instead be feature > checks? For example, CLOCK_MONOTONIC_RAW is behind a Linux ifdef and > CLOCK_MONOTONIC_FAST is

Re: [RFC wayland-protocols] inputfd - direct input access protocol

On Wed, 05 Apr 2017 at 17:45:51 -0700, Roderick Colenbrander wrote: > I wonder how Valve is doing this on Steam as with the Steam > Controller, which I haven't used. I think they are allowing it to > replace keyboard and mouse kind of. Curious how they are solving this. > My guess is they are

Re: [RFC] Interface for injection of input events

On Tue, 28 Mar 2017 at 15:33:41 -0700, Jordan Sissel wrote: > I am interested in the security concerns here, but are there reliable barriers > between different processes run by the same user in the same desktop session? > What is the threat model y'all are defending against? D-Bus was mentioned

Re: Collaboration on standard Wayland protocol extensions

re specifically designed to do this. A Wayland equivalent of D-Bus' GetConnectionCredentials() would probably be useful. S -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> ___ wayland-devel mailing list wayland-devel@lists.