[BRLTTY] BRLTTY, systemd and unprivileged user

[Aura Kelloniemi]

Hi

Dave Mielke <Dave at mielke.cc> writes:
 > [quoted lines by Aura Kelloniemi on 2020/08/23 at 01:21 +0300]
 > 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.

I don't use any graphical environments, except in special situations.

 > 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.

But aren't there two things to test?

First thing is whether BRLTTY runs correctly, if it is started as root, and it
changes the privileges it uses by itself. This can be tested by running it
from the build tree. This is a good thing to test, because there are many
people who do not (and don't want to) use systemd, so BRLTTY being
self-sufficient is great.

The other thing to test is whether the systemd configuration works. As far as
I understand, the brltty at .service defines the User, Group and
AmbientCapabilities because systemd is capable for setting them for BRLTTY by
itself. This I cannot test by running from the build tree, unless I install
the systemd config files, which has nasty consequences on my system.

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

I will send you the Arch package that I built and used to install the broken
BRLTTY. It can be extracted with GNU tar.

 > >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?

/usr/lib/sysusers.d/brltty.conf

 > 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.

Yes. Attached in this message is the Arcj build script that I wrote and used
to build the BRLTTY package.

 > >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.

They are owned by uucp and that seems to be what Arch udev rules do. Therefore
it would be nice if BRLTTY's install did not enforce creation of a dialout
group, because it being present on the system might make some other
application believe, that they should use this group (which does not have any
permissions anywhere).

 > >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.

Maybe using 'install -d -o brltty -g brltty -m0700 /var/run/brltty'. This does
not fail if the directory already exists, but fixes its permissions if needed.

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

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

Yes, sorry, I did not notice that when de-translating other messages.

 > >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.

crw------- 1 secret_user_name tty 4, 1 Aug 22 21:37 /dev/tty1

 > >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.

No, of course, but it should not have consequences except for one error
message. Or if it does, it is another bug to be hunted.

 > >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.

I'm actually very amazed that BRLTTY is so smart that it dug this information
from the device node itself. Great work, I'd say.

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

At that point I still had all the rules, so it should not be that.

 > 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.

The problem of systemd-udev-settle (according to a sourcw I found using a
well-known search engine) is that it blocks the system bootup process. Because
BRLTTY is wanted by sysinit.target and BRLTTY depends on systemd-udev-settle,
then sysinit.target cannot be reached before /dev is ready, which might slow
down the boot. I have BRLTTY now running without this dependency (it is only
scheduled to be run before sysinit.target) and it works fine.

I guess that BRLTTY should stop using this deprecated unit and just be
self-sufficient – i.e. be able to handle the situation where /dev is not
populated. It seems to be doing already very well.

-- 
Aura

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PKGBUILD
URL: <http://brltty.app/pipermail/brltty/attachments/20200823/945b84fb/attachment.ksh>