You are not logged in.

#1 2019-04-06 17:00:26

replabrobin
Member
Registered: 2010-05-06
Posts: 212

what's the correct setup to make beep work

After an upgrade today to beep-1.4.4-1 I found I couldn't get beep to work with sudo; I tried to follow the commands at

https://github.com/spkr-beep/beep/blob/ … ISSIONS.md

I got the second udev rule to work with both vtty use and also with a windowed background task I couldn't manage
to make the background process work with the first udev rule (which uses setfacl).

Is there a correct setup for an arch beep group?

Offline

#2 2019-04-06 20:17:13

seth
Member
Registered: 2012-09-03
Posts: 26,378

Re: what's the correct setup to make beep work

lsmod | grep pcspkr

Offline

#3 2019-04-06 21:13:27

Ropid
Member
Registered: 2015-03-09
Posts: 1,068

Re: what's the correct setup to make beep work

@seth, you seem to have misunderstood what the problem here is about. That 'beep' program behaves like this in its latest version:

$ sudo beep
[sudo] password for ...:      
beep: Error: Running as root under sudo, which is not supported for security reasons.
beep: Error: Set up permissions for the pcspkr evdev device file and run as non-root user instead.

$ su -c beep
Password: 

As you can see, it refuses to run when started through sudo. It will run fine when using 'su' instead of sudo.

I also just now tried the following, and it seems what it does is look for SUDO_* entries in the environment:

$ sudo -i

# beep
beep: Error: Running as root under sudo, which is not supported for security reasons.
beep: Error: Set up permissions for the pcspkr evdev device file and run as non-root user instead.

# unset SUDO_GID SUDO_COMMAND SUDO_USER SUDO_UID

# beep

Offline

#4 2019-04-06 21:40:54

seth
Member
Registered: 2012-09-03
Posts: 26,378

Re: what's the correct setup to make beep work

D'ooh m(
(Both, because i skipped the actual post and went for the common solution and because the beep behavior - while discouraging the UID0 execution for regular users is nice, this is nuts)

Ok.
The first rule is for active sessions (systemd controls the ACLs) and will never work for background processes.

Here's a list of groups to avoid for beep (or any other): https://wiki.archlinux.org/index.php/De … D_Database

This will also work:

sudo env -u SUDO_GID -u SUDO_COMMAND -u SUDO_USER -u SUDO_UID beep

Offline

#5 2019-04-07 10:37:23

replabrobin
Member
Registered: 2010-05-06
Posts: 212

Re: what's the correct setup to make beep work

Thanks for the pointers. I do have the module loaded so problems are not with that. Since beep is not an allocated group I chose to make that group and add my user to it. Using the second rule allows my background process to run beep. Would I be better off just adding my user to the input group?

Offline

#6 2019-04-07 13:15:38

seth
Member
Registered: 2012-09-03
Posts: 26,378

Re: what's the correct setup to make beep work

It's discouraged, https://wiki.archlinux.org/index.php/Us … emd_groups
Since the speaker device is technically not "input" I also don't know whether that makes sense (notably since you've a lot of GIDs left ;-)

Offline

#7 2019-04-18 13:27:39

schard
Member
From: Hannover
Registered: 2016-05-06
Posts: 1,309
Website

Re: what's the correct setup to make beep work

I am encountering the same issue.
Before some recent update, I could use "sudo beep" from an account to use the system speaker.
Now I get the error message mentioned above.
I tried the following according to the wiki to no avail:

$ cat /usr/lib/udev/rules.d/70-pcspkr-beep.rules 
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", GROUP="beep", MODE="0620"
$ udevadm control --reload
$ sudo -su termgr
$ beep
beep: Error: Could not open any device
$ groups
termgr sshusers beep

Update: False alarm. It works after a reboot somehow. hmm

Last edited by schard (2019-04-18 13:34:17)

Offline

#8 2021-02-17 13:51:26

radiobla
Member
Registered: 2020-02-19
Posts: 65

Re: what's the correct setup to make beep work

I was able to solve the issue by adding the rules suggested by @schard.

To avoid rebooting, I just reloaded both udev and the pcspkr module

After adding UDEV rules to /usr/lib/udev/rules.d:

# rmmod pcspkr
# modprobe pcspkr
# udevadm control --reload

I'm not sure if using "modprobe" instead of "insmod" is going to work as well. In my common sense, I'd say it would work the same way in this case.

Thank you.

Offline

Board footer

Powered by FluxBB