[quoted lines by Didier Spaier on 2021/11/10 at 23:18 +0100] >> > I start brltty like this: >> > brltty -d /dev/tty2 -b tt >> > >> > To get an output on /dev/tty2 I need to login in this tty, as the regular >> > user >> > who started brltty.
I should've thought of this back when you wrote that. If you have a login prompt on tty2 and also tell brltty to use it for a virtual braille device then you'd have a conflict. Both would be writing to tty2, and both would also be reading from it. You should be telling brltty to use a tty that's otherwise free. >I need to press Alt+F2 (or Ctrl+Alt+F2 to switch to text mode from a >graphical >environment), then the login name, press Enter, type type the password, then >press Enter again. After that the output of brltty is displayed in /dev/tty2 >as >expected. It is displayed immediately if I have logged in in /dev/tty2 prior >to >start brltty from another tty as the same user. This sounds like a permission issue. Have a look in brltty's log to see if there are any warnings and/or errors. >After brltty has been started for user X with -d /dev/tty2 anything displayed >in another tty (even the login prompt so before anyone be logged in in this >other tty)) is also displayed in /dev/tty2 (as an output of brltty). Are you starting brltty, then, as a regular user? If so, then it'd only be able to open a tty that's owned by that user. Of course, once already opened then access to it will remain. A tty, when not used, is owned by root:tty but it's owning user is switched to the actual user during a logged in session. I think this explans what you're describing. > >> > If I start brltty as root, no matter what, I don't get an output in >> > /dev/tty2. >> >> Does the log contain any errors? Perhaps you need to use -ldebug. > >Like below (timestamps removed): >checking braille device: /dev/tty2 >braille device type: serial >checking for braille driver: tt >initializing braille driver: tt -> /dev/tty2 >cannot open serial device: /dev/tty2: Permission denied This is why. It indeed is a permission issue. When you say "started as root", do you mean from a logged in root session or via sudo? >Indeed using a tty as braille device is not what blind users will do, but >maybe >for testing. Understood. This is exactly why both the tt (tty) and xw (XWindow) braille drivers exist. >But these tests were intended as a way for a sighted packager to check if >isolating the brltty outputs for two regular users (maybe not using the same >Braille table) was possible, as asked by Pawel Loba. The answer is no as far >as >my tests can say. This is confirmed by two blind users having tested using >the >same package, namely Patrick Delavalade and Tony Seth, in CC, using braille >displays. Brltty does text and contraction table autoselection based on the configured locale. So each user shouldn't specify either table, and, rather, just set $LANG when invoking brltty. If they need to specify the table, e.g. if the table is set within brltty.conf, then set the table to "auto". >Hence this question: What really brings to the user the ability to start >brltty >as regular user? added security? I fail to understand how. Setting the needed capabilities on the brltty executable and giving the user it's running as the needed group memberships. You wouldn't want to be giving a regular user those privileged group memberships so, instead, you need to set it up so that brltty switches to its own user. This can be requested via "privileged-parameters user=" and enabled via capabilities or the set-uid permission. >Further, to display the login prompt on a braille device brltty should then >be >started during the init sequence as a regular user (but which one, then?). I >can't check if it works myself. Yes. You should have a separate brltty instance defined for each user. You can do this with a systemd service named [email protected]. Doing this causes it to look for /etc/brltty_whatever.conf, so each user will then have its own configuration file. >As an aside, I still fail to grasp how these changes practically increase the >security of the system, including switching to a regular user if started as >root. It's not perfect, but, then, "increasing" doesn't imply "perfect". It means that brltty can't do anything - just what it needs to be able to do. >For the records here are the outputs I get starting brltty as root: >brltty: kernel module not installed: pcspkr This one could be since not all systems have that particular kernel module. It enables brltty to use the internal beeper device for alert tunes. Of course, not all systems have one of those. >and as regular user: >brltty: kernel module not installed: pcspkr Same answer. >Additional question: I don't ship the pcspkr driver in Slint kernels to avoid >that Alsa consider this device as the default sound board, hence the messages >above. Well, that answers the above two logs, then. I'm surprised that ALSA would make such a silly decision. It hasn't ever happened to me and I do use the beeper, hence the pcspkr module, for alert tunes. >Is pcspkr really needed by brltty and for what purpose? I personally think that the beeper is much nicer for the alert tunes, but the user can also select pcm for the tune device, which will then use the sound card. -- 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: [email protected] | Ottawa, Ontario | Twitter: @Dave_Mielke Phone: +1 613 726 0014 | Canada K2A 1H7 | _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
