You are not logged in.
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
lsmod | grep pcspkr
Offline
@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
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
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
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
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.
Last edited by schard (2019-04-18 13:34:17)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
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