cups denied access to /etc/shadow

[James Bardin]

Binary package hint: cupsys

cups prompts for a password, but permission is denied.
same result in web cups web interface.
Calling 'sudo system-config-printer' succeeds

Cups is being denied access to /etc/shadow in syslog:
[80999.467146] audit(1192212163.502:140): type=1503 operation="file_mmap" requested_mask="mr" denied_mask="m" name="/etc/shadow" pid=5054 profile="/usr/sbin/cupsd"

Shouldn't cups be using pam?

[James Bardin (jbardin-deactivatedaccount)]

Using gusty, updated 10/12

[Till Kamppeter (till-kamppeter)]

The user account created as the first one on the system (or accounts created as privileged accounts) are in the group "lpadmin" (see /etc/group). They can do CUPS administration without password. They can call commands like system-config-printer or lpadmin without sudo. Check whether the desired accounts are in the lpadmin group. In the web interface of CUPS (http://localhost:631/) these users use their own user names and passwords.

For other users and for access with basic authentication passwords are needed. I do not know how CUPS exactly verifies the passwords. AFAIR it uses PAM. The problem looks for me that AppArmor prevents the access to the passwords. The AppArmor configuration (/etc/apparmor.d/usr.sbin.cupsd) of CUPS seems to need a change. Note that the protection also applies to sub processes. So if CUPS calls some module of PAM, the PAM module is probably also restricted.

For a test try

sudo aa-complain cupsd

for AppArmor not blocking anything, only giving warnings in the log file. Does it work then.

sudo aa-enforce cupsd

gets you back to the default state.

[James Bardin (jbardin-deactivatedaccount)]

Till Kamppeter wrote:
> The user account created as the first one on the system (or accounts
> created as privileged accounts) are in the group "lpadmin" (see
> /etc/group). They can do CUPS administration without password. They can
> call commands like system-config-printer or lpadmin without sudo. Check
> whether the desired accounts are in the lpadmin group. In the web
> interface of CUPS (http://localhost:631/) these users use their own user
> names and passwords.
>
Thanks.
That's it. I didn't realize that cups was using the lpadmin group. I
also assumed that the user tool added the user to the correct groups.

Maybe there should be another bug report
"users-admin fails to add new admin user to lpadmin group"

I think "Administer the system" should include membership in lpadmin.

-jim

[Till Kamppeter (till-kamppeter)]

So please go ahead and report a bug on the user setup tool.

[Martin Pitt (pitti)]

Uploaded, in the unapproved queue now and waiting for approval.

[Martin Pitt (pitti)]

cupsys (1.3.2-1ubuntu6) gutsy; urgency=low

  * debian/local/apparmor-profile: Allow 'm' (executable mmapping) of
    /etc/shadow. This does not actually extend privileges since it is already
    readable, and does not actually make sense, but some weird backends want
    to do it nevertheless. (LP: #152061)

 -- Martin Pitt <email address hidden> Sun, 14 Oct 2007 22:01:31 +0200

[James Bardin (jbardin-deactivatedaccount)]

This will reduce the apparmor errors, but you will still receive errors if cups calls pam for an authentication method other than /etc/shadow.

The real problem seems to be that a new administrator isn't added to the lpadmin group. see bug 152107.
There is no option related to printer administration in the users-admin tool, and you would need to read cups.conf to find out you need to add the user manually to lpadmin.

[Till Kamppeter (till-kamppeter)]

Thank you for the link to the real bug. This is a regression from Feisty (probably patch dropped or so) and this should be easy to fix. No one of the developers has seen that bug report yet. I have milestoned it now.