We currently only allow use of most of the chown family of syscalls for chowning to root:root. https://github.com/snapcore/snapd/pull/4247 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, 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?
https://github.com/snapcore/snapd/pull/4247 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.