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.
I cannot reproduce. Add new printer shows a list of printers for me.
One possible explanation (but doubtful), user I tested with is an admin, ie, a member of the wheel group.
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
OK, maybe an implicit dependency is missing, can you try: dnf group install "Printing Support" and see if problem(s) persist?
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.
(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!
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.
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.
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.
I said this in the original report: "If root privs are needed then it should prompt me for a root password."
FEDORA-2020-1d45151aee has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1d45151aee
FEDORA-2020-c515fea44f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c515fea44f
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.
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.
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.
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.
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.
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.
Fixed in F31 and above.
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
Yes, unfortunately