[BRLTTY] BRLTTY, systemd and unprivileged user

[Dave Mielke]

[quoted lines by Aura Kelloniemi on 2020/08/23 at 01:21 +0300]

>Could you recommend me an easy solution which allows me to install and run
>BRLTTY with reduced privileges, and then return to the full privileges version
>(blindly) when it shows "No screen". 

I think it's better to do this kind of testing using a text console so that you
don't have the added complexity of knowing which brltty instance Orca is
connecting to.

You don't need to install an experimental brltty in order to test it. Instead,
just build it and then run what you just built by using the run-brltty script
in the top-level of the source tree. Even easier is to write a small wrapper
script for that which specifies all the desired options and then run that
wrapper with no opsions. The options you give to run-brltty are exactly those
that you'd give to brltty itself.

>I have a spare display available that I can use,

Good. Specify the options for it, e.g. driver and device, when invoking
run-brltty.

>but I probably cannot have multiple BRLTTYversions installed at the same time,
>because the systemd files need to be in place.

there are ways, but it's so much easier to test without installing by using the
run-brltty script.

> > i'm wondering if you may have a mixture of older and newer systemd units/files.
>
>Should not be.

Sure, but one must never make assumptions, i.e. one must check everything, when
things don't seem to be working right. Trusting oneself should be ones own
worst enemy.

Could you please send me all of your systemd-related files so that I can have a
look at them?

>I had brltty.path, brltty at .path, brltty at .service, udev rules, and sysusers and
>tmpfiles configuration files. 

What's the path to your installed sysusers file for brltty?

>I also had the brltty user and groups defined,

What's the output of the commande: id brltty

>but the problem can be there, if systemd did not generate them properly.

That's one of the things that we need to investigate.

>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: continuing to execute as the invoking user: brltty

So it isn't actually being started as root. This makes sense because that's
what systemd is being told to do. Let's first test with you invoking run-brltty
as root, though, to verify that the problem in somewhere within what systemd -
not brltty - is doing.

>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: capability not permitted: cap_sys_module
>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: capability not permitted: cap_setgid

It looks like systemd didn't add the capabilities to brltty's process.

>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: path not group readable: /dev/uinput
>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: path not group writable: /dev/uinput

This is a known issue and we provide a udev rule to correct for it. Please also
send a copy of your brltty udev rules file for inspection.

>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: 977(brlapi)

I'm guessing that you have /etc/brlapi.key, and that it's owned by the brlapi
group. That, by the way, is exactly hw I do it.

>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: 987(uucp)

This one is odd. Are your serial devices, e.g. ttyS0, owned by the uccp group
rather than by the dialout group? Maybe there are two (or more) "standards" for
serial device ownership.

>elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: cannot create directory: /run/brltty: Permission denied

This problem needs to be fixed. For now, maybe you should just manually create
the /run/brltty directory. The solution will probably be for brltty at .service to
use ExecPre to create it.

>elo 19 10:15:32 solaria systemd[1]: brltty at -dev-bus-usb-003-004.service: Can't
open PID file /run/brltty/brltty--dev-bus-usb-003-004.pid (yet?) after start: Operation not permitted

This is a symptom of /run/brltty/ not having been created.

>BRLTTY fails to open /dev/tty1 (Permission denied) 

I guess that's what "Lupa evätty" means.

>even though it manages to join the group tty (/dev/tty1 is owned by my user
>and has group tty).

What are its permissions? Tle whole ls -l output line would be interesting to
see. In any event, this shouldn't be an issue if brltty is running as root.

>The only group missing is dialout, because I already removed the systemd files
>shipped with brltty (to get it running as root).

That wouldn't remove brltty believing that it needs access to it.

>dialout should not be needed for screen access though.

It isn't - it's for serial device access. On your system, however, it seems
that the uucp group might be used for this.

> > For now, disable brltty's udev rules.
>
>I will, and I probably never need them, since I always use one display, and I
>want it to be managed by a single BRLTTY instance regardless of whether I'm
>using bluetooth or USB.

That, however, may be why you aren't benefitting from the rule to fix the
/dev/uinput access problem.

>This is an excerpt from /lib/systemd/system/systemd-udev-settle.service:
># This service can dynamically be pulled-in by legacy services which
># cannot reliably cope with dynamic device configurations, and wrongfully
># expect a populated /dev during bootup.

Well, brltty can. It does so by retrying, which can mean that it'll connect to
the device somewhat later than as soon as possible. That's why it depends on
that service - so that it'll start as soon as udev is ready.

-- 
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke            | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc  | Ottawa, Ontario   | Twitter: @Dave_Mielke
Phone: +1 613 726 0014 | Canada  K2A 1H7   |