In my opinion, desktop printers tools should trigger actions as same desktop user account. lpadmin group ever should be allowed on all related features.
__________ I'm using this express-made address because personal addresses aren't masked enough at lists.debian.org archives. El 25/11/16 a les 13:10, Didier 'OdyX' Raboud ha escrit: > Hi there Till, > > Le jeudi, 24 novembre 2016, 16.33:40 h CET Till Kamppeter a écrit : >> there is a long-standing bug report in Ubuntu (…) about that one cannot stop >> or delete print jobs from the "Printers" section of GNOME Control Center. >> >> The trivial-looking fix is to add root to the system groups (see comment >> #17), via a ./configure option (from patch of comment #24): >> (…) >> Is there any reason not having root in system-groups? Does Debian solve >> this problem another way? > > As you can see in https://bugs.gentoo.org/show_bug.cgi?id=466338 , upstream > points to the fact that as cups-pk-helper runs as root (really !?), it > "talks > to CUPS" as root, and not as the user doing the requests. > > https://bugs.debian.org/698504 has a partial fix for that, but it only fixes > "user in lpadmin can now talk to cups-pk-helper". I suspect Debian users have > just grown to put routinely put their users in the 'lpadmin' group. > > Digging history, the 1.0.2-1 changelog entry (from 17 years ago) has: >> Created "lpadmin" group and set SystemGroup to this. This will >> fix problems with CUPS not being usable initially. As soon as >> bug #50620 gets fixed, I'll set up to add root to the group, which >> will make root able to configure CUPS immediately after installation. > > This never happened, apparently. We can either do that (put 'root' in the > 'lpadmin' group on upgrade), or add the 'root' group as SystemGroup. > > I don't spot immediate flaws or possible regressions created by adding the > 'root' group as SystemGroup, and kinda-like the original plan (keeping > 'lpadmin' the only group allowed to administer CUPS). > > Opinions ? >
