Bug 32153

Thank you for the report.
Unsure of the validity of the procedure here.
'system-config-printer' is maintained by different packagers, so assigning this bug globally.

Source RPM: system-config-printer => system-config-printer-1.5.18-1.mga9.src.rpm
Assignee: bugsquad => pkg-bugs

On my system, using
http://localhost:631/printers/Boomaga
to pause the printer accepts my user name and password (doesn't require root).
Using it to resume the printer works without re-entering the id/password,
as it's remembered at that point.

Using that to set the printer to reject jobs, and then using
system-config-printer to start it, it's asking for my user password, not
roots.

$ rpm -q -i cups-pk-helper|grep ^Summary
Summary     : A helper that makes system-config-printer use PolicyKit

Whether policyket requires root or the user password is controlled by which
groups the user is a member of.

On my system, using
http://localhost:631/printers/Boomaga
to pause the printer accepts my user name and password (doesn't require root).
Using it to resume the printer works without re-entering the id/password,
as it's remembered at that point.

Using that to set the printer to reject jobs, and then using
system-config-printer to start it, it's asking for my user password, not
roots.

I've added my id to the adm and wheel groups. Don't forget to logout/in
after making group changes.

CC: (none) => davidwhodgins

Also keep in mind, cups can be accessed over a network. The admin likely
will not want someone without physical access to the printer to be able
to start it, so the default is only root can start it.

It does not seem normal to me as a system administrator in the company, that a local user has to call me to activate the printer because he cannot print.

The same goes for Mageia installations at other customers/friends. On several occasions I have been told that they can't print and it was because the printer was paused?

As per comment 2 and 3, that is expected and considered normal.

Defaulting to allowing users, who have not been given the authority, to start
printers would be considered a denial of service security bug, since it
automatically includes the ability to stop them too.

system-config-printer uses policykit to control who can or can not stop and
start printers.

If you want the users to have the authority, add them to the wheel and adm
groups, or convince the authors of system-config-printer to change how it
handles security. That would probably require changes in cups too.

Closing as invalid. This is not a bug in Mageia's implementation of the package.

Oops. Forgot to actually close.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Note that cups-pk-helper is specifically there to give you, the system admin, fine-grained control over what cups operations can be performed by other users without authentication. You can add a custom rules file in /etc/polkit-1/rules.d/ to override the default rules. See https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-security-policykit.html for details. This is much preferred to adding users to the wheel/adm groups.

The action you would want to change the rules for would be org.opensuse.cupspkhelper.mechanism.printer-enable.

CC: (none) => mageia

Created attachment 13931 [details]
/etc/polkit-1/rules.d/99-my.polkit.rules

I created the attached polkit rule to allow members of the group testers to
enable/disable printers. After logging into as a test user that is a member
of the testers group, I tried system-config-printer. It wants to install
task-printing-hp, which is already installed, and fails to run.

Looking at /usr/bin/system-config-printer, it runs
prefix=/usr
exec ${prefix}/share/system-config-printer/system-config-printer.py "$@"

Running /usr/share/system-config-printer/system-config-printer.py directly
works, without requesting any password, as is wanted.

The tester id has everything set to defaults.
$ id
uid=1001(tester) gid=501(tester) groups=501(tester)

Any idea why system-config-printer.py is failing when run using exec but then
working when run directly?

Argh. Never mind. Found the problem and it was caused by somehow setting
o-x on /usr/bin/rpm. I'll try to track down how that happened and fix anything
else that was unintentionally changed.

With the https://bugs.mageia.org/attachment.cgi?id=13931 policykit rule
in /etc/polkit-1/rules.d/99-my.polkit.rules, enabling or disabling a
printer works for a newly created user in the testers group.

To enable or disable a printer
- run system-config-printer
- double click on the printer
- select the Policies entry in the left part of the dialog
- select or unselect the "Enabled" box as desired
- select the Apply button
- enter the user's password when the password dialog opens

I suspect it's asking for the user's password because that user is also in the wheel or adm group. For me, it asks for the root password.

Delving into this, it looks like s-c-p doesn't support fine-grained permissions. The only action ID it seems to recognise is org.opensuse.cupspkhelper.mechanism.all-edit.

If you use the CUPS Web GUI, it does have finer-grained permissions, which can be configured in /etc/cups/cupsd.conf.

The user is not in wheel or adm, just the tester group.

I think it's due to me having set mcc/security/configure authentication for
Mageia tools to user password for system authentication.

That and not asking for a password for Mageia updates are the only non default
settings on this system.

s /on this system/on that page/