Snapping CUPS Printing Stack: Avahi support, system users/groups


We currently only allow use of most of the chown family of syscalls for chowning to root:root. fixes this to allow chown root:root <path>.


@till.kamppeter - applications (currently) don’t have access to processing logins via libpam. It is possible to add an interface for this, but it would be quite privileged in order to perform the authentication. The interface would also get potentially messy on (at least) classic since any number of pam modules might be installed on the system that might require additional accesses.

For now, compiling without pam is probably the way to go.


@jdstrand, thanks for the info. When will this feature make it into snapd?


@jdstrand, I compiled CUPS with --disable-pam now, but now I get this when trying to log into the admin page of the web interface:

Nov 17 20:11:09 virt-devel kernel: [32519.550607] audit: type=1400 audit(1510956669.146:2017): apparmor="DENIED" operation="open" profile="snap.cups.cupsd" name="/etc/shadow" pid=7272 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Nov 17 20:11:09 virt-devel kernel: [32519.550609] audit: type=1400 audit(1510956669.146:2018): apparmor="DENIED" operation="open" profile="snap.cups.cupsd" name="/var/lib/extrausers/shadow" pid=7272 comm="cupsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Is there a way to make CUPS accessing these files?

#86 was merged today and will be in snapd 2.30. I don’t know when that will be released, but I think I heard early December.


@jdstrand, any thought about this? Without PAM CUPS reads the /etc/password and /var/lib/extrausers/shadow files directly, to see whether the user logged in into the web interface is in the adm group (in the future libadm, when this problem is solved). This way the web interface would work correctly.


The ‘account-control’ interface allows managing extrausers so you would get access to the extrausers shadow file, but this isn’t the right interface for what you want. The problem is that your snap is trying to authenticate users against the configured databases for the system and we don’t (currently) have interfaces that support this.

To support this we would need very clear use cases and to understand exactly what we would want to support. Your application initially wanted to authenticate against PAM which might use local databases, ldap, kerberos, winbind, etc which makes writing an authentication interface tricky. I think ideally, snapd would proxy authentication requests so that the raw files aren’t exposed to the snap. Eg, rather than giving CUPS access to /etc/shadow, CUPS asks snapd if a given user/password pair is valid. In this manner, the snap only has access to authentication credentials that the user input, and not everything on the system. I suspect this could be done via a PAM module supplied by snapd (which would have to be very carefully written). This needs design.

Before that can happen, can you precisely describe the different mechanisms that that CUPS uses to authenticate users?


I never have looked into which authentication methods CUPS supports. I have hit into this only now. At least CUPS supports PAM (what probably is used in the standard desktop .deb packages of CUPS), accessing local user/password files (probably through some library function, what it did now after compiling with --disable-pam), and also more sophisticated enterprise network methods like for example Kerberos).


@till.kamppeter - this thread is getting fairly unwieldy. The discussion about authentication is different than what this topic is about. Can you create a new topic for ‘user authentication in snapd’ describing how and why CUPS is authenticating users on the system as opposed to maintaining its own authentication db (ala htpasswd). Feel free to copy/paste my comments from Snapping CUPS Printing Stack: Avahi support, system users/groups. When that is done, we can involve others more easily.

User authentication in snapd

@jdstrand, I have opened the new topic “User authentication in snapd” for this problem now.