Bug 1862581 - warnings and failures on gtk launch by user "B" when "A" started X11
Summary: warnings and failures on gtk launch by user "B" when "A" started X11
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: xdg-desktop-portal-gtk
Version: 8.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 8.0
Assignee: David King
QA Contact: Desktop QE
Depends On:
TreeView+ depends on / blocked
Reported: 2020-07-31 18:13 UTC by Need Real Name
Modified: 2020-08-03 20:52 UTC (History)
0 users

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Last Closed:
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)
Part of /var/log/messages (4.38 KB, text/plain)
2020-07-31 18:36 UTC, Need Real Name
no flags Details

Description Need Real Name 2020-07-31 18:13:09 UTC
Description of problem:

If user "A" starts X11 with "startxfce4" and user "B" runs in a terminal window (by either "ssh -Y B@localhost" or "su - B" followed by "export DISPLAY=:0.0" then when "B" runs gtk(+?) based applications an assortment of warnings to the screen and /var/log/messages appear.  These do not appear when "A" owns X11 and "A" starts the gtk(+?) application.  This was first noticed when "A" was root and "B" was a regular user account "modules".

Version-Release number of selected component (if applicable):
(some representative components):

CentOS Linux release 8.2.2004 (Core) 

How reproducible:

Steps to Reproduce:
0. Install a gtk(+?) application.  I use "meld".  That is not available
in RedHat (last I looked) but it is easy to install with:

#as root
cd /tmp
wget https://download.gnome.org/sources/meld/3.20/meld-3.20.2.tar.xz
unxz meld-3.20.2.tar.xz
tar -xf meld-3.20.2.tar.
cd meld-3.20.2
dnf install intltool  #if not already installed
python3 setup.py install --prefix=/usr
#3.20.2 is still the current version as this is posted
1. Set system to boot without X11
2. login as user "A", run: startxfce4
3. open a terminal, become "B" by either:
   ssh -Y B@localhost
   su - B
4. In "B"'s window run a gtk application, I use "meld".
  cd /tmp
  echo one >one
  echo two >two
  meld one two

Actual results:

Warning message appears in "B"'s window:

(meld:2869): dbind-WARNING **: 09:18:29.352: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

It tries to start 4 xdg applications:

modules    22474       1  0 10:25 ?        00:00:00 /usr/libexec/xdg-desktop-portal
modules    22479       1  0 10:25 ?        00:00:00 /usr/libexec/xdg-document-portal
modules    22483       1  0 10:25 ?        00:00:00 /usr/libexec/xdg-permission-store
modules    22494       1  0 10:25 ?        00:00:00 /usr/libexec/xdg-desktop-portal-gtk

If it succeeds (su - B) then in /var/log/messages one of these will appear each minute:

Jul 31 10:19:16 poweredge journal[22337]: Failed to get application states: GDBus.Error:org.freedesktop.portal.Error.Failed: Could not get window list: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag

If it fails (ssh -Y B@localhost) only 3 will start and /usr/libexec/xdg-desktop-portal will time out.  

Expected results:

No warnings in terminal window, no repeating warnings in /var/log/messages.
(I do not know how many xdg processes should start and remain running.)

Additional info:

See thread:


Similar tests on Ubuntu 18.04.4 had varying results.  The "su - B" case worked as expected (once a single file protection issue was resolved).  However, "ssh -Y B@localhost" had failures similar to those seen on CentOS 8.2.  xdg-desktop-portal-gtk is only 1.0.2 on that platform.  

The latest Fedora has 1.7.1 for xdg-desktop-portal-gtk, 
RedHat/CentOS AppStream has 1.6.0-1.

Comment 1 Need Real Name 2020-07-31 18:36:40 UTC
Created attachment 1703136 [details]
Part of /var/log/messages

Attached is part of /var/log/messages resulting from "meld" being run in an "ssh -Y modules@localhost" terminal.  Meld eventually started and then it was closed before this extract ends.

Comment 2 Need Real Name 2020-08-03 20:52:07 UTC
Probably related to bug #1793293

Note You need to log in before you can comment on or make changes to this bug.