Bug 408512 - Add support cups-pk-helper or kauth/policykit equivalent
Summary: Add support cups-pk-helper or kauth/policykit equivalent
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_printer_manager (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: Nicolas Fella
URL: https://github.com/apple/cups/pull/5638
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-10 08:53 UTC by Jonathan Wakely
Modified: 2020-03-12 23:17 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2019-06-10 08:53:28 UTC
SUMMARY

When a non-root user tries to add a new printer the "Add a New Printer" dialog opens and gives an error saying "Failed to get a list of devices: 'Forbidden'".

STEPS TO REPRODUCE
1. Open print manager as non-root user.
2. Try to add a printer.
3. Be sad.

OBSERVED RESULT

Failed to get a list of devices: 'Forbidden'

EXPECTED RESULT

Prompt for root password, so printers can be detected.

SOFTWARE/OS VERSIONS

Operating System: Fedora 30
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.58.0
Qt Version: 5.12.1
Kernel Version: 5.1.6-300.fc30.x86_64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz
Memory: 62.8 GiB of RAM

Also seen with:

Operating System: Fedora 29
KDE Plasma Version: 5.14.5
Qt Version: 5.11.3
KDE Frameworks Version: 5.58.0
Kernel Version: 5.0.9-200.fc29.x86_64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz
Memory: 31.0 GiB of RAM


ADDITIONAL INFORMATION

Clicking "System Preferences" prompts for a root password, but then doesn't do anything.

Running "kdesu kcmshell5 printer_manager" manually allows the printer to be configured. The printer manager should do that automatically if it's necessary.
Comment 1 Rex Dieter 2019-06-10 16:00:56 UTC
Probably related to distro defaults wrt cups, 

what works for me:  if user is in "wheel" group (ie, to designate them as an admin user), everything works as expected.

what does not work:  if user is not in wheel group, precisely as this report details.  Both adding/remove printer actions fail and clicking "System Preferences" prompts for a root password, but then doesn't do anything. 

I'd expect the latter case to both prompt for elevated credentials and then work properly.
Comment 2 Rex Dieter 2019-06-10 16:07:59 UTC
Confirmed problem remains testing latest kde-print-manager-19.04.2-1.fc30.x86_64 release
Comment 3 Nicolas Fella 2019-08-23 14:45:37 UTC
It works for me if the user is in the wheel group and /etc/cups/cups-files.conf has wheel in SystemGroups

I've made a patch for CUPS to have wheel there by default: https://github.com/apple/cups/pull/5638
Comment 4 Nate Graham 2020-03-10 20:42:10 UTC
The patch was merged, looks like this is fixed now.
Comment 5 Jonathan Wakely 2020-03-10 22:18:59 UTC
I don't consider this fixed. It should be possible for non-admin users to add a printer. Requiring me to add my user to the wheel group is not a "fix". Yes, I know the Fedora default is to add users to wheel, but I override that during installation.

kdesu or equivalent functionality should be used to get elevated privs in order to add the printer.
Comment 6 Nate Graham 2020-03-11 02:12:05 UTC
Unfortunately, whether or not adding printers requires root is entirely something controlled by the distro, not anything we have input over in KDE land. If you don't like it, your options are to go bug your distro, or use a different distro.
Comment 7 Jonathan Wakely 2020-03-11 06:45:19 UTC
Why can't you prompt for a root password to get elevated privileges temporarily?
Comment 8 Jonathan Wakely 2020-03-11 13:12:12 UTC
Let me try and explain this differently. My original report said:

EXPECTED RESULT
Prompt for root password, so printers can be detected.

That's what I still think should happen. If the user happens to have admin privs due to distro settings, or the specific config on a specific machine, or because the user is root, then there's no need to prompt. Great, it Just Works.

But it seems very silly, and unsafe, to say that the solution to "this operation needs elevated privs" is that all distros should give elevated privs to normal users, all the time (or that users should only use less secure distros).

If an operation needs elevated privs, ask for them. That's what KAuth is for:
https://api.kde.org/frameworks/kauth/html/index.html

(In reply to Nate Graham from comment #6)
> your options are to go bug your distro, or use a different distro.

As a distro maintainer, I consider this is an irresponsible and even dangerous statement.
Comment 9 Kevin Kofler 2020-03-11 15:08:06 UTC
The way this is supposed to work in Fedora (and it has been like that for 11 years!) is that CUPS has PolicyKit integration: https://fedoraproject.org/wiki/Features/CupsPolicyKitIntegration

See also:
https://www.freedesktop.org/wiki/Software/cups-pk-helper/
https://wiki.archlinux.org/index.php/CUPS#Allowing_admin_authentication_through_PolicyKit

The UI is supposed to interact with that. The Ubuntu way of letting anyone control printers without a password is not going to happen in Fedora, and requiring users to be in wheel is also not useful.
Comment 10 Rex Dieter 2020-03-11 15:40:31 UTC
marking this as wishlist, and adjusting summary as a feature request.
Comment 11 Nate Graham 2020-03-11 15:57:47 UTC
That makes sense to me.
Comment 12 Nicolas Fella 2020-03-11 21:49:37 UTC
https://phabricator.kde.org/D23403 should fix this
Comment 13 Kevin Kofler 2020-03-11 23:03:10 UTC
This is not as nice as PolicyKit support, but it will do the job.
Comment 14 Nicolas Fella 2020-03-12 23:17:31 UTC
Git commit 9a11a1f4de8a26999485148c5a78e160e8880f17 by Nicolas Fella.
Committed on 12/03/2020 at 23:18.
Pushed by nicolasfella into branch 'master'.

Fix authentication

Summary:
According to the CUPS code (https://github.com/apple/cups/blob/master/cups/auth.c#L105) cupsDoAuthentication returns 0 on success and -1 on error. The code was assuming the opposite

Now the CUPS password dialog is shown when needed. This is quite often, e.g directly at startup due to getServerSettings() so it might be worth checking if that's really necessary.

Test Plan: Open print-manager with a user that is not in a CUPS system group. Privileged operations work after entering a password

Reviewers: dantti, broulik

Reviewed By: dantti

Subscribers: ognarb, rdieter, kde-utils-devel

Differential Revision: https://phabricator.kde.org/D23403

M  +2    -2    libkcups/KCupsConnection.cpp

https://commits.kde.org/print-manager/9a11a1f4de8a26999485148c5a78e160e8880f17