On Tue 29 Nov 2016 at 08:17:32 +0100, Didier 'OdyX' Raboud wrote: > Le lundi, 28 novembre 2016, 17.07:14 h CET Till Kamppeter a écrit : > > On 11/28/2016 03:29 PM, Brian Potkin wrote: > > > I added root to SystemGroup in cups-files and restarted cups. A queue > > > was paused with cupsdisable. From g-c-c it was possible to cancel the > > > job without unlocking the printing dialog. After unlocking I was able > > > add/delete printers, start/stop a printer set a default printer and > > > apparently change queue options. > > > > > > Sabotage of fine-grained privileges by cups might not go down well. :) > > > > Then I would suggest to actually add root to SystemGroup. > > What I understand from Brian's argument is as follows: adding 'root' to > SystemGroup allows any user to administer CUPS through cups-pk-helper as if > she were member of 'lpadmin' without a password prompt.
I was also thinking the present OOTB behaviour would be broken and could lead to cups having a critical (makes unrelated software on the system break) bug filed against it. Is that too fanciful? > In other words, letting cups-pk-helper run as 'root' (but accept commands > from > any allowed users) leads to a user-to-lpadmin privilege escalation. At least, > it defers access control away from CUPS to cups-pk-helper. > > If cups-pk-helper runs as root, could it not drop privileges, and run the > CUPS > commands as the originating user? Or use the CUPS API for cancelling jobs. s-c-p probably does it because there no problem with this when it uses c-p-h. -- Brian.
