[BRLTTY] permissions on the brlapi.key file

[kendell clark]

hi

I think I understand, brlapi.key is set that way to be more secure. 
Would specifying read access by everyone, but write and execute access 
to root only compromise the security? After all, orca only needs to read 
the file, not change it. I don't mean to ask for anything unreasonable, 
but some of my users are   ... very demanding. They expect to plug in 
their display, either via usb or bluetooth, and have it work 
immediately. If they have to do so much as a single thing, this is hard 
windows just works, or mac just works depending on what they used before 
sonar sucks.  Never mind that they had to set their screen reader to use 
that braille display it wasn't automatic on their other platform, which 
probably used brltty as well lol. Most of my sonar users are very 
understanding though so this is a minority, but it does happen. By the 
way, I never understood just how great brltty was until I had a display 
to test with. It works beautifully.

Thanks

Kendell Clark



On 08/27/2016 11:06 PM, Dave Mielke wrote:
> [quoted lines by kendell clark on 2016/08/27 at 17:00 -0500]
>
>> there is one minor thing I'd like to fix in brltty's package build script so
>> that braille more or less works out of the box, at least for USB displays. The
>> reason orca was having so much trouble with the braille sense wasn't the
>> display or orca, it was the permissions that were set on the /etc/brlapi.key
>> file. It was owned by root and readable only by root. I was able to fix this
>> by entering "sudo chmod 755 /etc/brlapi.key" in a terminal, after which
>> everything worked. Is it possible to specify something like "install -d -m 755
>> /etc/brlapi.key" in the package build script so that this works automatically?
> This boils down to what is and what isn't a good security policy. What you're
> effectively asking for is the generation of a secret key that, by default, is
> made public. Of course, once a key is made public then there's no point in ever
> trying to restrict it since, befopre restricting it, anyone could've made a
> copy of it.
>
> Perhaps the best thing to do is for the default to be that brltty is installed
> with no brlapi security. Then, if desired, brlapi security could be activated
> as desired, at a later time, by a system's administrator.
>
>> I'm not sure if brltty comes with it's own brlapi.key file or if brltty itself
>> generates it. If it generates it, can permissions on it be set in the config
>> file? I'm trying to find a way to fix it so that sonar users can simply plug
>> in a display and have it work without having to change the permissions
>> themselves.
> Couldn't initial Sonar setup include setting the permissions on
> /etc/brlapi.key? They may not need to be as wide open as 644, by the way. Orca
> usually runs as the gdm user, and the primary group for the gdm user is usually
> gdm. As I see it, therefore, the best thing to do might be to make
> /etc/brlapi.key be owned by the root user and the gdm group, and for its
> permissions to be 640.
>