[BRLTTY] BRLTTY, systemd and unprivileged user

[Dave Mielke]

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

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

Okay. I thought you might've been because of your reference to the "no screen"
message.

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

Yes, exactly! And I'd also like to test this on your system anyway, just to be
sure that that part of the code isn't contributing to the problem.

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

Okay, This is how I do it:

First, I create /brltty/ and make it owned by me so that I don't need to be
root to install under it. Then I configure with my cfbrltty script (which runs
configure). It sets the install location to /brltty/REV-BRLTTY-*, where * is
the release number and commit identifier. For example, I have:

   /brltty/REV-BRLTTY-6.1-419-g8dbe71bd

If you're wondering, the value is determined by running the getrevid script.
The cfbrltty script takes care of this so you don't need to worry about it.

The next thing I do is add a symbolic link named current to /brltty/ which
links to the release that I'd like to be running. For example:

   cd /brltty/
   ln -s REV-BRLTTY-6.1-419-g8dbe71bd current

Actually, I cheat a bit so that I'll be less likely to mistype it. I do it like
this:

   ln -s *-419-* current

Now you need to tell brltty's systemd wrapper script where the brltty
executable is that it's supposed to run. This is done by telling systemd to set
the BRLTTY_EXECUTABLE_PATH environment variable. cd to the directory where
brltty at .service is, create the brltty at .service.d subdirectory, and cd into it.
You can have any number of *.conf files within this subdirectory, and they'll
all apply to the brltty@ service. I have a file named wrapper.conf that
contains (without the indentation):

   [Service]
   Environment=BRLTTY_EXECUTABLE_PATH=/brltty/current/bin/brltty

Then, of course, you'll need to run: systemctl daemon-reload

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

Yes, this'll be fixed. It already checks which group /dev/ttyS0 is owned by -
dialout is hard-coded just in case, so I'll remove that.

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

Sure.

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

The underlying C function that converts an error code into text, strerror(),
translates to the configured locale's language. This is one case where, perhaps
selfishly, I'd rather it didn't. Anyway, nothing you need to be sorry for.

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

Some hacker will figure it out! :-) Anyway, it looks good.

So, just to get my understanding correct, when you start brltty as root, and it
doesn't switch to an unprivileged user, is it having the tty1 access problem?
I'm confirming because it doesn't seem to make any sense.

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

Okay. I didn't realize that, and shall remove the dependency.

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