[BRLTTY] permissions on the brlapi.key file

[Tom Masterson]

Dave is correct.  The best answer is to make it owned by root and group (Gdm might work well for gnome) and make it rad write by root and read by the group.  If you make a key universally readable it is no longer a secret key.  You then make the users that need access to brlapi part of the group.  Of course if everyone who uses the computer is to have access to brlapi you could then make brlapi.key readable by all.  It only needs to be writable to root and does not need to be executable at all.

Tom

Sent from my iPhone

> On Aug 27, 2016, at 21:41, kendell clark <coffeekingms at gmail.com> wrote:
> 
> 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.
> 
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty