[BRLTTY] Issue linking brlapi and orca.

Didier Spaier didier at slint.fr
Sun Sep 17 18:49:12 EDT 2017


Hello,

Le 17/09/2017 à 03:04, Dave Mielke a écrit :
> [quoted lines by Didier Spaier on 2017/09/15 at 20:10 +0200]
> 
>> Does that implies that the braille device should be connected before
>> booting? Or will this work if the device is connected after the daemon
>> has started?
> 
> You should be able to connect the braille device at any time - even long after 
> the boot has completed. I believe that both orca and xbrlapi (assuimg that 
> you're using recent releases) automatically retry until the BrlAPI server is 
> available. Of course, you should verify this as I'm not 100% sure.

OK. I will take your words for granted as I have no  braille device at hand ;)

> What I've said is true for USB devices, assuming that you're using brltty's 
> udev rules, because connecting a USB braille device automatically starts a 
> brltty process dedicated to that device. For Bluetooth and/or serial devices, 
> however, you'll need an additional brltty process that's started during the 
> boot and stays running. Enabling brltty.target (assuimg you're using systemd) 
> will do this.

Well, we'll start brltty at boot time by default. The user can change that
chmod'ing 755 vs 644 a daemon manager /etc/rc.d/rc.brltty conf.

Slint doesn't include systemd. The init system is somehow similar to BSD's
I think, ans starting software ala sysvinit is also available.

>> Also, I had first commented all lines under:
>> Application Programming Interface Parameters in /etc/brltty.conf
>> and I assume that this is not safe.
> 
> I'm not sure what you mean. I'm suspecting that you mean "uncommented" (not 
> "commented"). Doing that is only unsafe if any of those lines specifies 
> something you don't want.

No, I really meant commented, each involved line beginning with a #
(aka U+0023).

> In general, those commented lines show what the defaults are.

In brltty 5.5 in brltty.conf.in I see:

#api-parameters Auth=keyfile:@CONFIGURATION_DIRECTORY@/@api_authkeyfile@	# Require authentication key
#api-parameters Auth=user:joe		# Allow some local user
#api-parameters Auth=group:brl		# Allow some local group
#api-parameters Auth=polkit		# authenticate via Polkit

To make sure that I understand correctly, does this mean that these
methods being tried one after the other as soon as one condition is met
the connection is allowed? I ask as having left this part of the config
file as is I could get a connection. By the way can I check which method
succeeded and how? Would strace help?

>> Currently I include this code snippet in brltty's post-install script:
>> ---
>> if [ ! -f etc/brlapi.key ]; then
>> 	chmod 755 usr/sbin/brltty-genkey
>> 	usr/sbin/brltty-genkey etc/brlapi.key
>> 	usr/bin/chgrp braille etc/brlapi.key
>> 	chmod 640 etc/brlapi.key
>> fi
>> ---
> 
> In my opinion, you should be using absolute paths. This code is assuming that 
> the current directory is /, which may well be true, but it shouldn't be 
> assuming it. It's just my opinion, of course, but I really think you should add 
> the leading slashes.

Well, I should have given more context. This code is run by the script
that installs the package, named installpkg, not directly by the user.
Also it has to work also in the context of the installer. In this case
/ is the root of the initramfs and the root partition of the system to
install is /mnt. For post-installation tasks installpkg first cd to
/mnt, that's why there are no leading slashes.   

> I think you should be invoking brltty-genkey by just its name - not by its path 
> - and letting the shell find it wherever it is. 

Well, I could do that if I check that both /mnt/usr/sbin and /usr/sbin
are in root's path as installpkg is also used in the installed system.
Although given the context I don't see a risk here.

> I think that you shouldn't be using chmod to make it executable. Firstly, it 
> should simply already have been installed that way. Secondly, an administrator 
> may want the freedom to make it unexecutable as a way to disable it.

Well, this code snippet is used during intallation of the pacakage and
of course the adminstrator may change that after installation.
   
>> I assume that this fits the setting below in /etc/brtty.conf:
>> api-parameters Auth=group:braille
> 
> No. That parameter means that the client eitehr needs to be in the braille 
> group or have braille as one of its supplementary groups. If that's true then 
> the file (brlapi.key) won't even be checked.
>
>> If, say, I am more lenient and allow all local connections like this:
>> api-parameters Host=:0
> 
> This parameter has nothing to do with authorization (Host= isn't Auth=). It's 
> specifying that the server will be waiting on the port for BrlAPI session #0. 
> Specifying Host= is usually only ever necessary when you're running more than 
> one brltty process.

Thansk for the clarification.

>> Then could I have root:root own /etc/brlapi.key and make it 644?
> 
> YOu could do that, but that'd remove all restrictions. Also, if that's what you 
> really want then it's simpler to specify Auth=none.
> 
>> Is the increased security allowing only members of the braille group
>> worthwile? 
> 
> If it's your own system, and only you and maybe other trustworthy people use 
> it, then sure. I wouldn't dare be to casual with anyone else's system, though.

OK, I will keep /etc/brlapi.key 640 with owner:group root:braille then.

>> Bear in mind that I am searching a convenient default
>> setting for Slint, that the admin could of course change after
>> installation.
> 
> This comes down to personal opinion. Is it better to have no security and place 
> the responsibility on the administrator to remember to tighten it up, or is it 
> better to be reasonably secure while allowing an administrator to loosen it up. 
> It's your decision.

We'll try to be reasonably secure with above settings.

Best,
Didier



More information about the BRLTTY mailing list