Bug 499041

Summary:	Administrator account can lock themselves out of printer access
Product:	[Applications] systemsettings	Reporter:	frafortunelli
Component:	kcm_printer_manager	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	CONFIRMED ---
Severity:	major	CC:	nate, noeerover
Priority:	NOR
Version First Reported In:	6.2.5
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description frafortunelli 2025-01-23 07:25:30 UTC

SUMMARY
Administrator account can lock themselves out of printer access by defining another user as the allowed user for a printer and readding the printer as an administrator does not work. 

STEPS TO REPRODUCE
1. Log in as admin user
2. Have at least 1 printer set up. 
3. go to settings -> printers -> open print queue -> configure -> banners policies and allowed users -> allow these users to print -> type in a username that is not the current user
4. Printer disappears from settings 
5. Set up printer again 
6. Printer disappears from settings 

OBSERVED RESULT
The admin user can lock themselves out of being able to use a printer. 

EXPECTED RESULT
The admin user can re-add themselves to the allowed users for a printer in some way.  

SOFTWARE/OS VERSIONS
Operating System: Bazzite 41
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.1
Kernel Version: 6.12.9-203.bazzite.fc41.x86_64 (64-bit)

ADDITIONAL INFORMATION
Logging into the secondary user the printer was specified under and deleting specified user as only allowed user or adding admin user to allowed users makes it so that disappearing printer is now visible from admin account.

Comment 1 Nate Graham 2025-01-23 15:40:11 UTC

Whoops!

Comment 2 Mike 2025-01-23 16:14:10 UTC

Interesting.  If I go to localhost:631, manage printers, it's there and you can modify users.  When selecting "Allow these users to print", it remains "hidden" from print-manager (kcm, configure-printer).  However, when selecting "Prevent these users from printing", it's back.

I think it might the way that our CUPS request calls getDevices (which, BTW, is using a deprecated api):
```
m_connection->retry("/admin/", CUPS_GET_DEVICES)
```

Also, configure-printer uses a similar query method and it fails silently when trying to load that printer at startup.

AFAICT, none of that code has not changed in over 10 years.  I'll see if testing with the "new" stuff  makes any difference with the KCM.

Helluva find.

Comment 3 Mike 2025-01-23 16:17:16 UTC

ugh, my grammer....

Anyway, even our new stuff with the proper (modern) CUPS api calls produces the same results.

Comment 4 Mike 2025-01-23 16:22:40 UTC

I should also add, that's with CUPS 2.4.11.  At some point in the near future, we'll be able to test with CUPS 3.x as well.