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: [email protected]
For general information, go to: http://mielke.cc/mailman/listinfo/brltty