md_39118 schriebEs sieht also nicht gut aus was eine Fehler Behebung angeht.
Es wäre eigentlich ganz einfach, wenn nur der Maintainer mal etwas engagierter wäre. Wenn er meint, es wäre kein Bug, dann soll er den Bugreport schließen und es auch begründen, andernfalls soll er das PKBUILD wie vorgeschlagen ändern und das Paket neu bauen und verteilen.
Ich kann trotzdem noch nicht nachvollziehen, wie das Problem überhaupt entstanden ist. Ich habe noch das Paket cdrtools-3.02a09-2 im Paketcache, und da ist u. a. für cdrecord das suid-Bit gesetzt (Modus 104711), deshalb funktionierte bis dahin der Aufruf für den unprivilegierten Benutzer auch, mit pkgrel 3 hatte sich das geändert, jetzt ist das Bit nicht mehr gesetzt (Mode 100711) und deshalb lässt es sich vom Benutzer auch nicht mehr ausführen.
Die PKBUILDs der Packagereleases 2 und 3 unterscheiden sich aber nur durch die Änderung des Release, und die Quellen von Schilling haben sich seit dem 10.12.2017 auch nicht geändert, und wenn ich beide Pakete mit dem Release 2 und 3 baue, bekomme ich auch immer nur ein cdrecord ohne gesetztes suid-Bit. Da frage ich mich schon, wie das Paket cdrtools-3.02a09-2 entstanden sein könnte, es lässt sich nämlich aus den offiziellen Quellen nicht mehr so bauen, wie es verteilt wurde.
Aus den Kommentaren geht auch nicht hervor, warum das Paket am 07.07.20 überhaupt neu gebaut werden musste. Dort wird nur "reproducibility rebuild" als Grund genannt. Wenn ich das Paket mit dem im Bugreport angebotenen PKBUILD-Patch baue, der ja nur in install-sh die Variable "rootflag" von FALSE auf TRUE setzt, wird das suid-Flag auch wieder gesetzt und cdrecord lässt sich wieder wie vorher durch den Benutzer aufrufen.
Damit ergeben sich für dich diese Optionen:
(1) du setzt manuell das suid-Bit auf cdrecord, dann hast du wieder den gleichen Zustand wie in dem Paket cdrtools-3.02a09-2 (so hatte ich es seinerzeit auch gemacht)
(2) falls du cdrtools-3.02a09-2 noch im Paketcache hast (oder aus dem Archiv
https://archive.archlinux.org/packages/c/cdrtools/cdrtools-3.02a09-2-x86_64.pkg.tar.xz holen), downgrade durchführen und das Paket auf hold setzen, bis der Maintainer das Problem behoben hat
(3) das Paket selber unter Einbeziehung des angebotenen Patches für PKBUILD (bzw. install-sh direkt patchen) neu bauen
Eigentlich gibt es überhaupt keine Möglichkeit, ohne Änderungen an den Rechten von cdrecord dem Benutzer die Möglichkeit zu geben, es zu verwenden. Die Änderung der Gruppe in "optical" ist genau so eine Krücke, die vom Entwickler Schilling nicht vorgesehen ist. In sofern kannst du dir dann aussuchen, welche Krücke dir angenehmer ist.