[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Darn 'beep' stoped working after installing Stretch in place of Jessie

On Mon, 31 Jul 2017, Juan R. de Silva wrote:

Hi folks,

I installed (fresh install instead of an upgrade) Debian Stretch on my laptop.
The installation is full success without any problem except a little one -
'beep' does not produce a sound neither from CLI nor from a bash scripts. I had
Jessie installed on the same laptop before and it worked just fine.

I checked everything I possibly could: pcspkr module loaded, alsa does not have
any muted channels, tried to use it as a user and as a root. No clue why it does
not work any longer in Strech.

Any suggestions?

Possibly the following excerpt from https://github.com/johnath/beep/
applies. (TLDR: Skip to the end, read the last three quoted lines.)

| A note about ioctl
| ------------------

| As noted in the man page, some users are running into a situation
| where beep dies with a complaint from ioctl().  The reason for this,
| as Peter Tirsek was nice enough to point out to me, stems from how
| the kernel handles beep's attempt to poke at (for non-programmers:
| ioctl is a sort of catch-all function that lets you poke at things
| that have no other predefined poking-at mechanism) the tty, which is
| how it beeps.  The short story is, the kernel checks that either:

| - you are the superuser
| - you own the current tty

| What this means is that root can always make beep work (to the best
| of my knowledge!), and that any local user can make beep work, BUT a
| non-root remote user cannot use beep in it's natural state.  What's
| worse, an xterm, or other x-session counts, as far as the kernel is
| concerned, as 'remote', so beep won't work from a non-priviledged
| xterm either.  I had originally chalked this up to a bug, but
| there's actually nothing I can do about it, and it really is a Good
| Thing that the kernel does things this way.  There is also a
| solution.

| By default beep is not installed with the suid bit set, because that
| would just be zany.  On the other hand, if you do make it suid root,
| all your problems with beep bailing on ioctl calls will magically
| vanish, which is pleasant, and the only reason not to is that any
| suid program is a potential security hole.  Conveniently, beep is
| very short, so auditing it is pretty straightforward.

| Decide for yourself, of course, but it looks safe to me - there's
| only one buffer and fgets doesn't let it overflow, there's only one
| file opening, and while there is a potential race condition there,
| it's with /dev/console.  If someone can exploit this race by
| replacing /dev/console, you've got bigger problems.  :)

| So the quick solution is beep is not beeping when you want it to is:

| $ su
| Password:
| # chmod 4755 /usr/bin/beep

| (or wherever you put it)

| The one snag is that [making beep suid root] will give any little
| nitwit the ability to run beep successfully - make sure this is what
| you want.  If it isn't, a slightly more complex fix would be
| something like:

| # chgrp beep /usr/bin/beep
| # chmod 4750 /usr/bin/beep

| and then add only beep-worthy users to the 'beep' group.

Reply to: