It appears that app-misc/beep changed its behavior and the program, though compiles fine, does not actually work anymore. It appears have added safeguards against standard setuid options that are currently specified in the ebuild. (It now also prohibits using sudo as well.) Reproducible: Always Steps to Reproduce: 1. build app-misc/beep 2. switch to unprivileged user who is at the console 3. run beep at command line Actual Results: $ beep beep: Error: Running setuid or setgid, which is not supported for security reasons. beep: Error: Set up permissions for the pcspkr evdev device file instead. Expected Results: speaker should have beeped. My system is using openrc-elogind-pulseaudio. I suspect a udev rule is also needed to allow the pcspkr device (/dev/input/by-path/platform-pcspkr-event-spkr/) to also allow logged in user to access it.
I guess related to: commit 51db2842c8c2c925a6c0d7c7875949e94afa9d6f Author: Alessandro Barbieri <lssndrbarbieri@gmail.com> Date: Mon Feb 22 02:02:52 2021 +0100 app-misc/beep: capabilities added, suid removed Closes: https://bugs.gentoo.org/716734 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Alessandro Barbieri <lssndrbarbieri@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/19588 Signed-off-by: Michał Górny <mgorny@gentoo.org>
Yes, the logic in ebuild for suid is still there for 1.4.9-r1 and it doesn't really do anything, it just gives an error. That whole section for USE=suid probably should be removed including fperms. I'm still not exactly certain what is needed to reliably get the speaker to beep. Currently I've chmodded the input pcspkr devices and need to have pavucontrol running to get it to beep, which I don't quite understand (suspect my laptop routes the pcspkr 8253 emulation output through an input of hd-audio to save an extra speaker) but permissions may still need some work. I think I also have a problem with my ext4fs not having extended attributes working and this may also be part of the problem that make capabilities not work, but this seems like more feature bloat/complexity which isn't needed for embedded (though not an issue for a workstation/laptop). Simple program, added complexities...
@Ben do you still have this problem? I can't reproduce by app-misc/beep-1.4.12 under my pc. see below for some information of the program: $ ls -l /usr/bin/beep -rwx--x--x 1 root root 28552 12月12日 20:12 /usr/bin/beep $ getcap /usr/bin/beep /usr/bin/beep cap_dac_override,cap_sys_tty_config=ep
Strange, the ebuild still has fperms 0711 /usr/bin/beep -- how is your system not setting the suid bit or are you post processing this? Again the machine I'm working on does not appear to have extended attributes working, probably a kernel misconfig (should there be a warning about this or part of gentoo-sources requiring extended attributes/capabilities?), I'd have expected portage to complain about this somewhere like other programs that put the caps/attributes in the sandbox, and then need to transfer caps from the sandbox to the main filesystem?
after reread the ebuild,i find the reason: 1. the caps mode are set by "fcaps" in pkg_postinst, but fcaps will set SUID silently if file system doesnt't have xattr support, see /var/db/repos/gentoo/eclass/fcaps.eclass 2. the program disable suid/sgid support, sugguest use udev to setup the permission, see PERMISSIONS.md (which is not installed in docs, to be fixed) currently, add the user to input group is a quick fix. But beep warn on do so, it suggest to add a new group 'beep' instead.
I read your patch, I think this wording might make it easier to read: elog "Please note that for security reasons, beep will no longer allow" elog "SUID or sudo. You will need to give permissions for the PC speaker" elog "device to allow non-root users to use 'beep':" I recall a file somewhere that kept track of devices that belong to console much like /dev/dri/* and /dev/snd/* but can't remember what that was... perhaps the speaker device should likewise be handled the same way.
(In reply to Ben from comment #6) > I read your patch, I think this wording might make it easier to read: thanks, and updated. > I recall a file somewhere that kept track of devices that belong to console > much like /dev/dri/* and /dev/snd/* but can't remember what that was... > perhaps the speaker device should likewise be handled the same way. the device are setup by udev, man beep said: The device files beep uses by default are the following: /dev/input/by-path/platform-pcspkr-event-spkr /dev/tty0 /dev/vc/0 so I choose the first one as a example, if more case or more general case found, we can update then.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=01e878219667bf8ce1781f7b74758ecf40ecb80b commit 01e878219667bf8ce1781f7b74758ecf40ecb80b Author: Z. Liu <zhixu.liu@gmail.com> AuthorDate: 2024-12-13 09:39:03 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-24 09:20:47 +0000 app-misc/beep: fix issue when no caps on fs w/o xattr support 1. set mode so fcaps won't set SUID if fs w/o xattr support 2. show message tell user howto run as non-root user 3. add more doc files Closes: https://bugs.gentoo.org/877095 Signed-off-by: Z. Liu <zhixu.liu@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/39706 Signed-off-by: Sam James <sam@gentoo.org> app-misc/beep/beep-1.4.12-r1.ebuild | 60 +++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
