Interface request: "cups-control" on CUPS snap and including D-Bus

[jamesh]

@jdstrand

To address this, we discussed that a patch could be developed similar to what was done for pulseaudio, where cupsd would:

• look at the PEERCRED of the connecting client process to obtain the pid/etc of the process
• in addition to cupsd’s normal group checks, it would ask snapd (eg, via snapd-glib or similar) to see if the connecting process is from a snap

Note that there isn’t such an API in snapd at present. The PulseAudio module I put together does this by checking the AppArmor label of the process. Xdg-desktop-portal does the same, but will be switching to check cgroups plus a call out to snap routine portal-info (it was done this way to avoid putting too much complicated logic on the x-d-p side).

Either of these strategies are possible under strict confinement with an appropriate interface, but they are not exactly simple.

@jdstrand

• make a decision based on this information. An initial implementation might simply deny access to admin functionality if the connecting process is a snap. A future implementation might have cupsd then ask if a specific interface is connected, and if so, allow the admin access (a suggestion would be to introduce a new ‘cups’ interface that allows access to the socket and only if cups-control is connected would admin access be allowed).

This patch should be upstreamed to Apple. @till.kamppeter said he would discuss patching cupsd with @jamesh and see if a PoC could be developed in time for an upcoming OpenPrinting summit. If they are amenable to the change, we can consider changes to snapd. In the meantime, distros could choose to distro-patch as desired.

I wonder if a better approach (and one more likely to be accepted upstream) would be to implement polkit support into CUPS? This has a number of benefits:

1. It will be useful on Linux systems not running snapd, so could gain support from other distros if Apple pushes back.

2. Polkitd can make access decisions based on the user’s host system user names or group memberships that a confined cupsd can’t see. This would make it possible to implement passwordless access for lpadmin members if desired.

3. If configured to require the user’s password (i.e. auth_admin or auth_admin_keep), then perhaps we don’t need the snap check: the polkit dialog will allow the user to cancel administrative actions before they are completed.

This would obviously require some further improvements to snapd: namely allowing snapped daemons to talk to polkitd:

Allow snapped daemons to use polkit authorisation

One request that has come up a few times is the ability for snapped daemons to make use of polkit authorisation. This essentially lets the daemon consult a system policy to decide whether to allow a non-root user to perform a particular action. When the polkitd daemon is absent, such applications typically fall back to requiring that the user be root. I’ve been doing some analysis to see what needs to be exposed to enable this feature, and what some of the potential security concerns are. C…

I think it is also worth keeping in mind that we have a solution available to allow applications to print without connecting the cups-control interface, in the form of xdg-desktop-portal’s print portal. Applications using GTK 3’s printing APIs can automatically use this interface. I think it would be better to steer applications towards that interface rather than following the audio-playback/audio-record model we used for Pulse Audio where the daemon makes the policy decision.