For as far as I am aware, it has been a recurring issue with Orca that applications run as root flat out don’t work with it. I’m curious if any work has been done to remedy this?
In particular, this hamstrings live system installers. Anything using Calamares, as well as for example the Parrot Security Installer just flat out doesn’t read anything due to this one issue.
I am helping a distro maintainer to make their distro accessible, but it uses Calamares, and they are unable to rebuild in such a way that the installer can run as non-root. What can be done here?
1 Like
Sorry for the long reply, but some background might be helpful in terms of
diagnosing the problem. In order for Orca to read an application, the
application needs to expose AT-SPI (the accessibility API) over dbus.
AT-SPI uses its own dbus server for this purpose, started by
at-spi-bus-launcher. Applications need to find the address for this dbus
server in order to connect to it. At-spi-bus-launcher exposes the bus
address in two ways. It is accessible via a method call on the session
bus, and, on X11, it is also stored as an X atom. In theory, the latter
allows applications running as root to find the accessibility bus on X
systems even if the session bus is different from the normal user’s
session bus.
I’m not sure if your installer is using Wayland or X11, but, if you are
using wayland and Calamares also has a different DBUS_SESSION_BUS_ADDRESS
value than what Orca has, then Calamares won’t be able to find the
accessibility bus.
Alternatively, there could be a bug in the QT accessibility code, or it
might be deciding that a screen reader isn’t running and that it doesn’t
need to enable accessibility. Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
in the environment might be another thing to try, at least for debugging
purposes; it will override QT’s accessibility detection and always enable
it.
Hth,
-Mike
Will share these suggestions in any case. This feels like it’s asking for trouble though:
- Users have no idea about ATSPI, don’t care about ATSPI and want their screen reader to work.
- devs barely know Orca is even a thing at all, let alone how it works under the hood. Distro maintainers idem ditto. They see Orca starts up, reads some things but not others and have no idea where to turn. Given how few distros are accessible out of the box, this kind of high entry threshold really doesn’t help matters. Has any thought been put into somehow making this less hostile?
I know that Calamares uses QT, and that 6 years ago there was some discussion about fixing things (Calamares is not accessible by screen reader (orca) . · Issue #470 · calamares/calamares · GitHub) but that ultimately, nothing came of it due to inactivity and upstream changes. I don’t know what Parrot Security uses for an installer, but it has the exact same problem going on from a user’s perspective. If there’s two, there’s more than likely more, which means all distros affected cannot be installed by a blind computer user as things currently stand.
As for Wayland vs x11, I am …reasonably sure Calamares at least uses Wayland these days but don’'t quote me on that.
Hello, the general long-term solution to this is to avoid running GUI applications as root, even installers. It is not safe to do that, for multiple reasons. The framework would have to separate out the GUI and the portions that require root, as in this comment: Accessibility bugs in calamares · Issue #523 · calamares/calamares · GitHub
Hello,
I guess the issue is not accessing apps running as root but more generalized making apps running as different user than the one running and at-spi. Is this even something we want to allow?
I think orca spawns at-spi if it’s not started by the desktop environment thus we need to make sure environments of other users are configured in a way so it can detect that at-spi bus.
On a live system that are two users one normal user and a root user.
I think the real solution would be similar to what is there on windows and possibly other platforms. When running apps as root or different user another instance of orca along with the accessibility stack including at-spi should be started with that user privileges.
Login session is already implemented this way on most systems. Perhaps this might be considered for the installer as well.
@jason:
You’re not wrong. Running GUI apps as root is a bad idea. It’s also very convenient for apps that require it somewhere down the line which is why everybody is doing it anyway when they even remotely require this. You see this on Windows, you see this on Unix …it doesn’t really matter where you go, people are going to be doing this.
And while I agree with you that it probably shouldn’t be happening, I don’t agree that we can just hand-wave this away as a “welp, apps just need to do better”. If we look back through the archives , people have been running into this as early as 2015. It’s pretty clear this pattern isn’t going to go anywhere anytime soon and while we wait, users have literally zero access to apps doing this,which in turn means they have no access whatsoever to distros that have an installer that does this. Which, even if we just look at Calamares, is a number of them, given a lot of arch-derived GUI distros use this. Calamares also appears to have lost its main paid maintainer which means i really don’t see this getting fixed on their end anytime soon.
Even so, Calamares isn’t the only one who does this. I like @pvagner’s solution of finding a more robust solution to this problem altogether and just allowing Orca to work with apps running as a different user. This will likely come up in all sorts of scenarios and practically everything out there in screen reader land does this better than Orca, at the moment.
Yes, that is why I said long-term solution. I don’t know the status of this on Windows, but on Linux you should never do it even if it is convenient. It will cause many other problems. You can probably come up with some short-term solutions to force access to the session bus, but they are basically all going to be hacks that further erode the security of the system and also cause those other problems to occur. Running another accessibility bus as root is not a solution, then you need to do even more hacks in Orca to try to get it to copy the settings from one user while it is running as another. And it also amplifies any security issues. If someone fixes this the correct way then you fix the giant security hole and you also just get the accessibility working correctly again “for free”.
But, if this framework has no maintainer then I would recommend those other projects switch to a different installer. You will run into many more problems without having an active maintainer to fix them. Sadly it seems many portions of the accessibility stack are under-maintained.
Hello, all GUI-based installers run as root because of when the application manages the disk, it needs to be root. It could be a good idea what you wrote above, that these installers should manage GUI and “privileged actions” in a separate manner". So all Linux distros using GUI installers like Calamares (that I think are becoming the majority) cannot be installed by people with sight defects. The only exception I see is on distros based on Debianinstaller framework like Kali Linux that should have a speech mode for installation (I didn’t test and I don’t know if it is based on orca). Since in Kali the installation in speech mode should work, it works in an environment that is running as root.
@mgorse I tried in a X11 environment and it is still not working.
@jfrancis in your opinion, which are the installers compliant with orca?
I am sorry, I have not researched this in depth so I have no suggestions for other installers. Note I am not even saying you need to find one compliant with Orca, at bare minimum you must find one that has active maintainers and then you can go from there.
If there are none that anyone knows of, then someone may have to find someone to take up maintainership, or start a new one with a focus on accessibility.
1 Like
Hi,
As an orca user, One of the installers that was used for manjaro was called thus and was very accessibile. Ubuntu at the moment use ubi quity. Also accessible. Debian uses a text installer with espeakup. The live images uses calemars however.
Matthew
The unprivileged GUI process should talk via D-Bus to a non-GUI process that is running as root, which will handle the privileged operations. It’s not a small amount of work, but this is the way to fix your problem. This is how all GNOME applications handle privileged operations.
1 Like
Thank you guys for your clarification.
@mdyer1 I should give a look to Manjaro with Thus installer. So it seems Manjaro uses both Calamares and Thus as installers. A user requiring more accessibility, should go to Thus. I will try it. Meanwhile, which accessibility feature Thus provides to you?
PS: I tried to use Manjaro GNOME but I cannot find the Thus installer. Is there a specific Manjaro ISO that uses Thus?
@mcatanzaro thank you for your clarification. That statement should be proposed to Calamares team since the most of Arch-based OS are based on it, I can write it to some issue ticket opened on this topic on their GitHub. It will be a huge effort but if they would like to be “competitive” among the several installers, they should be inclusive by thinking also to all people that could have sight problems.
Hi,
Last I heard, thus is no longerencluded. As f9or when it was used and how orca worked with it I was able to read the prompts and check the boxes for what I wanted installed. Also there was a linnux distro based on Manjaro called sonatr which sadely is no longer in exhistents.
Matthew
It is a pity for Thus installer, meanwhile I proposed the topic of this post to Calamares team in the last comments: Accessibility issue with Orca screen reader · Issue #1294 · calamares/calamares · GitHub
could cleared environment be the cause?
does it work if you run with sudo -E?