Bug 1718795 - Only superuser can configure printer in KDE
Summary: Only superuser can configure printer in KDE
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-print-manager
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-10 08:42 UTC by Jonathan Wakely
Modified: 2020-06-04 20:29 UTC (History)
6 users (show)

Fixed In Version: kde-print-manager-19.12.3-2.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-26 14:38:48 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
KDE Software Compilation 408512 NOR RESOLVED Add support cups-pk-helper or kauth/policykit equivalent 2020-06-04 20:29:05 UTC

Description Jonathan Wakely 2019-06-10 08:42:38 UTC
Description of problem:

Cannot configure printers as non-root.

Version-Release number of selected component (if applicable):

kde-print-manager-18.12.2-1.fc30.x86_64
kde-cli-tools-5.15.5-1.fc30.x86_64
kdesu-5.15.5-1.fc30.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Open System Settings -> Printers
2. Click "+ click here to add a new printer"
3. Dialog shows error "Failed to get a list of devices: 'Forbidden'"

Actual results:

Network printers cannot be detected.

Expected results:

If root privs are needed then it should prompt me for a root password.


Additional info:

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.

I get the same "Forbidden" error in F29 too, although I'm sure it used to work there at some point.

Comment 1 Rex Dieter 2019-06-10 13:15:54 UTC
I cannot reproduce.  Add new printer shows a list of printers for me.

Comment 2 Rex Dieter 2019-06-10 13:16:46 UTC
One possible explanation (but doubtful), user I tested with is an admin, ie, a member of the wheel group.

Comment 3 Jonathan Wakely 2019-06-10 13:33:16 UTC
My user is not in the wheel group.

I can reproduce this on two separate machines, one F29 and one F30.

When I click the button to add a printer I see this in the journal:

Jun 10 14:32:29 phinkdat.home cupsd[1225]: REQUEST localhost - - "POST / HTTP/1.1" 401 91 CUPS-Get-Devices successful-ok
Jun 10 14:32:29 phinkdat.home cupsd[1225]: [Client 1110] Returning HTTP Forbidden for CUPS-Get-Devices (no URI) from localhost
Jun 10 14:32:29 phinkdat.home cupsd[1225]: REQUEST localhost - jwakely "POST / HTTP/1.1" 403 91 CUPS-Get-Devices successful-ok

Comment 4 Rex Dieter 2019-06-10 15:36:42 UTC
OK, maybe an implicit dependency is missing, can you try:

dnf group install "Printing Support"

and see if problem(s) persist?

Comment 5 Rex Dieter 2019-06-10 15:50:57 UTC
OK, I can now confirm and reproduce once I took myself out of the wheel group.

Secondary bug which may or may not be related, clicking on "system preferences" prompts for root credentials, but then appears to do nothing.  I'll add my findings to the upstream report.

Comment 6 Jonathan Wakely 2019-06-10 16:08:09 UTC
(In reply to Rex Dieter from comment #4)
> OK, maybe an implicit dependency is missing, can you try:
> 
> dnf group install "Printing Support"
> 
> and see if problem(s) persist?

That just installed one additional package, which seems unlikely to help: mpage.
I didn't logout and relogin to confirm, but it didn't change anything immediately.


(In reply to Rex Dieter from comment #5)
> OK, I can now confirm and reproduce once I took myself out of the wheel
> group.
> 
> Secondary bug which may or may not be related, clicking on "system
> preferences" prompts for root credentials, but then appears to do nothing. 

Yup.

> I'll add my findings to the upstream report.

Thanks!

Comment 7 Brandon Nielsen 2020-04-15 19:43:00 UTC
I'm still seeing this behavior with Fedora 32 RC 1.3.

The user is still shown "Failed to get a list of devices: 'Forbidden'" upon landing in the add printer dialog. Continuing further through the process eventually prompts for privilege escalation, and works as normal.

Comment 8 Lukas Ruzicka 2020-04-16 08:43:54 UTC
I just come into this as a devil's advocate and ask this:

Isn't this the required behaviour of system printers? I mean, non-admin users should not be able to tweak the system outside of the scope of their home directory, which means, that they would not be able to manipulate system printers. So, I would not say that this is a bug if a non-admin user cannot add printers, but admin users and root can.

Comment 9 Jonathan Wakely 2020-04-16 10:36:31 UTC
The point is that the user should be prompted to enter a root password. It should not be necessary to log out, log in as root, configure a printer, then log back in as the normal user.

Nobody is asking for normal users to be able to add system printers without some form of escalated privs (e.g. via PolicyKit, kdesu, or some other means).

And it was just a silly bug in the upstream package which has now been fixed.

Comment 10 Jonathan Wakely 2020-04-16 10:37:02 UTC
I said this in the original report:

"If root privs are needed then it should prompt me for a root password."

Comment 11 Fedora Update System 2020-04-20 16:53:00 UTC
FEDORA-2020-1d45151aee has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1d45151aee

Comment 12 Fedora Update System 2020-04-20 16:53:54 UTC
FEDORA-2020-c515fea44f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c515fea44f

Comment 13 Fedora Update System 2020-04-20 22:37:12 UTC
FEDORA-2020-c515fea44f has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c515fea44f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c515fea44f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2020-04-21 18:43:13 UTC
FEDORA-2020-1d45151aee has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1d45151aee`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1d45151aee

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 15 Fedora Update System 2020-04-28 02:56:12 UTC
FEDORA-2020-c515fea44f has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Ben Cotton 2020-04-30 20:11:08 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 17 Fedora Update System 2020-05-01 00:35:52 UTC
FEDORA-2020-1d45151aee has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 18 Ben Cotton 2020-05-26 14:38:48 UTC
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 19 Jonathan Wakely 2020-05-26 19:00:07 UTC
Fixed in F31 and above.

Comment 20 Brandon Nielsen 2020-06-04 19:24:18 UTC
Testing the Fedora 33 Rawhide 20200604.n.0 compose[0], and while I agree the issue as originally described is "fixed", I'm curious if the new behavior is really working as intended.

The way it works now:

1. Open System Settings -> Printers, root password is requested
2. Enter root password
3. Click "Add Printer", root password is requested _again_

From this point, adding a printer works acceptably. Is it really intended that the user be prompted twice?

0 - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200604.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20200604.n.0.iso

Comment 21 Rex Dieter 2020-06-04 20:29:22 UTC
Yes, unfortunately


Note You need to log in before you can comment on or make changes to this bug.