[Bug 1231091] Re: Screenreader starts, but does not work with installer (ubiquity) in live session
** Merge proposal linked: https://code.launchpad.net/~thesquash/ubuntu/+source/ubiquity/+git/ubiquity/+merge/407632 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1231091 Title: Screenreader starts, but does not work with installer (ubiquity) in live session To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231091/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1231091] Re: Screenreader starts, but does not work with installer (ubiquity) in live session
I'm pretty sure I discovered the bug, and I think I know how to rectify it too.
Please note that this was a tricky bug to find and it made my head spin for a
while; it was only recently when I figured this out from start to end. Here's
what I know now:
I discovered that Ubiquity's greeter (`maybe-ubiquity`) starts two D-Busses:
the normal session bus, which non-root programs communicate over for
pretty much everything (including accessibility communications), and the
special accessibility bus, which is only used by root programs like Ubiquity.
The accessibility bus uses a special configuration file which allows root to
use the bus (normally root would be banned from the bus); that configuration
file is stored at /usr/share/defaults/at-spi2/accessibility.conf:
[...]
[...]
Depending on the version of Ubuntu in use, the exact application which requests
the accessibility bus in the first place (and thus the application which
requests the bus to be launched) differs. On stock Ubuntu, it is a portion of
the GNOME Settings Daemon; on Ubuntu MATE, it is consistently the Ubiquity
panel. Either way, which application starts the bus doesn't matter, as long
as an application starts it.
When an application requests the bus be started, the D-Bus daemon requests that
SystemD launches the `at-spi-bus-launcher` program. This program starts
another, separate D-Bus daemon (separate from the main session bus, that is),
and tells this new D-Bus daemon to use the aforementioned configuration file.
The bus launcher also requests that the new D-Bus daemon inform the bus
launcher about how the new D-Bus daemon can be addressed and contacted; the
applications need to know about this bus and they need to know how to
communicate on it. The D-Bus daemon tells the bus launcher how to contact it
when the D-Bus daemon has initialized itself fully.
Once the bus launcher knows how to contact the accessibility bus, the bus
launcher is supposed to set an *X11 atom* on the root window of the X session
which Ubiquity is using. The atom applied to the root window means that any
application, even Ubiquity, can quickly and easily find out how to communicate
over the accessibility bus. Here's an example of the atom:
$ DISPLAY=":0" xprop -root AT_SPI_BUS
AT_SPI_BUS(STRING) =
"unix:abstract=/tmp/dbus-jvfzJSsTTp,guid=e1dc67ddfb5b08287b1b9676612460d8"
This means that the accessibility bus can be reached using a UNIX domain socket
(so it can be accessed only on the local system); a proper call to "bind" to
the socket at `/tmp/dbus-jvfzJSsTTp` will connect to the accessibility bus
(though the `abstract` part means that the socket is not visible in the file
system; this is a Linux-only feature, and you'll sometimes see `path` instead,
which means the socket can be viewed as part of the file system); and in order
to verify that the application is authenticated to access the bus, it must pass
the globally unique identifier `e1dc67ddfb5b08287b1b9676612460d8` as proof that
it's not an external attacker.
Sounds straightforward, right? Wrong. How does the bus launcher know what the
address of the *X server* is? Sure, there is the `DISPLAY` environment
variable, and that is what the bus launcher tries to get access to; but in
general, on UNIX one process cannot get access to an environment variable
unless it inherited that variable from its parent.
So who's the parent of the bus launcher? You'd think it would be the Ubiquity
panel, for example, or the GNOME Settings Daemon, since those programs
*requested* the accessibility bus in the first place. Not so; remember how I
said that *the Ubiquity panel requests* that *D-Bus requests* that *SystemD
launches* the accessibility bus? (Yes, it really *is* that big of a game of
Telephone.) But the D-Bus session bus daemon doesn't know what the contents
of the X11 `DISPLAY` variable are -- I verified this -- much less does SystemD
know that. So how is the accessibility bus supposed to know what X11 display
to use??
This one took a lot of digging. Ultimately, it was just luck that I came
across the `/usr/bin/ubiquity-dm` program, which holds the key (excerpted from
line 407 et seq.):
if (
osextras.find_on_path("kwin") or
osextras.find_on_path("kwin_x11") or
osextras.find_on_path("gnome-shell")
) and osextras.find_on_path("dbus-update-activation-environment"):
subprocess.Popen(
[
"dbus-update-activation-environment",
"--verbose",
"--systemd",
"DISPLAY",
],
stdin=null,
stdout=logfile,
stderr=logfile,
preexec_fn=self.drop_privileges,
)
Okay, what's going on here? Let's break this down: If KWin or the GNOME Shell
are installed,
[Bug 1231091] Re: Screenreader starts, but does not work with installer (ubiquity) in live session
It's been well over a month since I last reported on this, so I think it's fine time I reported about the latest on the subject. My above comment was mostly correct and slightly wrong. Interestingly, stock Ubuntu 21.10 does not use Wayland (on my setup, at least, with Intel integrated graphics); it uses X11, just like Ubuntu MATE does. But interestingly, Ubiquity on stock Ubuntu starts the *GNOME Shell*, whereas Ubiquity on Ubuntu MATE only starts Marco, a generic Ubiquity top panel (which is supposed to be stocked with indicators, but Ubiquity's panel only works with Unity indicators and not Ayatana indicators), the MATE Settings Daemon, and a handful of other programs. Furthermore, like I suspected, both Ubuntu and Ubuntu MATE start the Ubiquity greeter as root, except their *effective* user IDs are both the respective live session users (`ubuntu` and `ubuntu-mate`, respectively). The latter is done probably to allow communication over D-Bus, because my experiments show that if the process' effective UID is not 999 (the live session user), neither version of Ubiquity will interact with the screen reader. Here's the proof. The first snippet was taken on an Ubuntu 21.10 system (that took me eons to download); the second is from an Ubuntu MATE 21.10 system. Ubuntu: RUSEREUSERPIDPPID COMMAND ubuntu ubuntu 19481941 /usr/bin/pipewire ubuntu ubuntu 19491941 /usr/bin/pipewire-media-session ubuntu ubuntu 19501941 /usr/bin/pulseaudio --daemonize=no --log-target=journal ubuntu ubuntu 19531941 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ubuntu ubuntu 19661941 /usr/libexec/dconf-service ubuntu ubuntu 19831703 /usr/libexec/gsd-a11y-settings ubuntu ubuntu 19861703 /usr/libexec/gsd-keyboard ubuntu ubuntu 19871703 /usr/libexec/gsd-media-keys ubuntu ubuntu 20041703 /usr/libexec/gsd-power ubuntu ubuntu 20051703 /usr/libexec/gsd-xsettings ubuntu ubuntu 20061703 gnome-shell --sm-disable --mode=ubiquity root ubuntu 20282009 /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --greeter --only ubuntu ubuntu 21512146 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 ubuntu ubuntu 21661941 /usr/libexec/at-spi2-registryd --use-gnome-session Ubuntu MATE: RUSEREUSERPIDPPID COMMAND ubuntu-+ ubuntu-+18821875 /usr/bin/pulseaudio --daemonize=no --log-target=journal ubuntu-+ ubuntu-+18931875 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ubuntu-+ ubuntu-+18961875 /usr/libexec/dconf-service ubuntu-+ ubuntu-+19261694 /usr/bin/mate-settings-daemon ubuntu-+ ubuntu-+19271694 marco --sm-disable ubuntu-+ ubuntu-+19311694 /usr/lib/ubiquity/panel ubuntu-+ ubuntu-+19381694 nm-applet ubuntu-+ ubuntu-+20001875 /usr/libexec/at-spi-bus-launcher ubuntu-+ ubuntu-+20072000 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 root ubuntu-+20081942 /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --greeter --only ubuntu-+ ubuntu-+20931875 /usr/libexec/at-spi2-registryd --use-gnome-session The output was abbreviated slightly; I remove unrelated processes like the RealtimeKit daemon and UDisks. As you can see, the Ubiquity process (`/usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity` on both of them) runs with a real UID of root, but an effective UID of either `ubuntu` or `ubuntu-mate` (the latter was chopped off by `ps`). So there's no dissimilarity there. ***However...*** With the screen reader enabled, from a command line (Ctrl-Alt-F2) I tried launching a text editor on each of them, first as user 999: DISPLAY=":0" pluma & ...and then as root: sudo env DISPLAY=":0" pluma & ...and then with a real UID of 0 and an effective UID of 999, just like Ubiquity: sudo env DISPLAY=":0" setpriv --ruid 0 --rgid 0 --euid 999 --egid 999 --init-groups pluma & The first command cooperated with the screen reader on both systems (i.e., the screen reader told me stuff like "Edit menu... Select All Ctrl-A"). The last two commands worked fine on Ubuntu but not on Ubuntu MATE. I tried these experiments also on the live desktop, not just at the Ubiquity greeter. The results were the same regardless of whether I tried it on the live desktop or on the Ubiquity greeter. Clearly, Ubuntu and Ubuntu MATE are configured differently, somehow pertaining to user IDs allowed to use accessibility features. But where? I ran the above experiments, but through `strace -s 1048576` to capture all (or most) communications going on between pluma / gedit and D-Bus. The
[Bug 1231091] Re: Screenreader starts, but does not work with installer (ubiquity) in live session
Regarding @hellsworth's observation (post # 11):
Though this observation may well lead us down the correct path, I
strongly believe both run as the superuser. Here's why:
For the record, the MATE desktop's window manager is Marco; the "window
manager" on stock Ubuntu is Mutter since stock Ubuntu uses the GNOME
desktop. Another thing to note is that stock Ubuntu tends to use
Wayland by default, whereas Ubuntu MATE exclusively uses X11 (mainly
because the MATE applications don't work very well on Wayland yet).
Marco adds the " (as superuser)" suffix to the end of windows which are
owned by the superuser. The Marco code which adds the suffix is located
on lines 486-491 in the source file `src/core/window-props.c` (see
https://github.com/mate-desktop/marco/blob/master/src/core/window-
props.c#L486-L491):
if (window_owner==0)
{
/* Simple case-- don't bother to look it up. It's root. */
*target = g_strdup_printf (_("%s (as superuser)"),
title);
}
I was going to look up whether Mutter has a similar block of code for
the function, but I discovered I didn't need to: On stock Ubuntu, the
maybe-ubiquity screen uses just a plain old, client-side-decorated
header bar, which bypasses the window manager's own decorations. I can
prove it since this screenshot (https://phoenixnap.com/kb/wp-
content/uploads/2021/04/choose-keyboard-layout-for-ubuntu-20.04.png)
shows Ubiquity's title bar without the menu button on the left side of
the window title bar; the menu icon (which is a group of three white
horizontal lines) always appears with the default Mutter settings if
Mutter draws the window title. Note that Mutter never draws the window
title on Wayland.
So in other words, just because one says it's run as the superuser and
the other doesn't say it does not mean that the other is not run as the
superuser. To find the real answer, we'd have to boot up a stock Ubuntu
to the maybe-ubiquity screen, press Ctrl-Alt-F1 to go to a console, log
in, and then use `ps` to find out who owns the `ubiquity` process.
However, furthermore it would be a good experiment to find out if the
Wayland / X11 difference is the culprit. I wonder if any accessibility
information is communicated over the X protocol, or if it's all done via
D-Bus?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1231091
Title:
Screenreader starts, but does not work with installer (ubiquity) in
live session
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231091/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1930312] Re: USB disks and SD cards mount for wrong user
For the record, this is not specific to Ubuntu or Ubuntu MATE at all -- I see this on Gentoo regularly, for example. It seems to be caused by a race condition in Caja and UDisks which didn't appear until UDisks started mounting volumes under user-specific subdirectories of `/media` -- so for example `user1` has volumes mounted under `/media/user1` and `user2` has volumes mounted under `/media/user2`. In ye olden days, `user1`'s UDisks-utilizing process (such as Caja) would mount the volume; `user2`'s instance of Caja would wait for the volume to get mounted by `user1`'s Caja, then open the shared mountpoint at `/media/[volume]`. Nowadays this doesn't work in any case, since `user1` puts in the request to mount the volume first and the volume is mounted under `user1`'s private mount directory -- `/media/user1/[volume]`. I'm not sure how to fix this yet, though. Maybe (but just a WAG) UDisks needs some kind of integration with the display manager or logind? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1930312 Title: USB disks and SD cards mount for wrong user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1930312/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
