Request autoconnection of `cups-control` for LibreOffice

This is required for printers to work in LibreOffice.

I don’t maintain this snap, Canonical does, maybe @oSoMoN can confirm that autoconnection would be a good idea here?

1 Like

Thanks @Ads20000 for starting this thread! If the security team is okay with it, I think it would be a good idea indeed, printing is a rather common task when using libreoffice apps.

@till.kamppeter: are there upcoming changes in the printing stack that would make such an auto-connection not necessary?

1 Like

As I said in the bug, the alternative is to wait until software centers support GUIs for connecting interfaces, but that’s going to be a while away, so autoconnection really would be good if the store and security teams are OK with that.

I don’t actually know when gnome-software is supposed to support this. I can say that cups-control give complete access to printing configuration (which also can allow a number of other escalated accesses), not just whether or not one can print or not to an existing printer. I thought driver-less printing was supposed to solve this?

I really don’t care for the cups-control interface because it gives away too much. That said, gnome-software is not here yet, and libreoffice is from a trusted publisher. A tepid +1 for auto-connection.

Is driveless printing something that distro releases from 1 or 2 years ago would support? Thinking about 14.04, 16.04 and other distros from that era.

But it doesn’t, for whatever reason?! It seems you still need to add a printer and have the program recognize the added printer for printing to work…

Don’t know, I’m afraid.

Hopefully @oSoMoN has more knowledge here…

1 vote for, 0 against. There are not enough votes to tally at this time.

@ratliff, @natalia, @evan, @mvo - can one/all of you vote on this?

There still aren’t enough votes to tally at this time.

@niemeyer, @ratliff, @natalia, @evan, @mvo - can one/all of you vote on this?

I’d like to see the questions @jdstrand and @sergiusens raised answered before weighing in. @oSoMoN and @till.kamppeter?

Not tallying until @evan’s question is answered.

Ping regarding @evan’s question. This request will not be granted until all open questions from reviewers are answered.

I do not exactly know what the cups-control slot is offering and for what it is good for. It is not made by me and not with my cooperation. It was simply there when I looked into the snapcraft documentation for the first time.
I am working on snapping the CUPS printing stack, see this thread. This snap does not provide any slot (yet).
What is needed for CUPS access (printing, listing printers, jobs, and options, also administration) is both access to the domain socket of CUPS and localhost:631. In reality only one of the socket and localhost:631 is needed but one does not know which of the two the local CUPS offers by its configuration.

I have introduced driverless printing in 17.04. So system-integrated (DEB packages) printing stacks in older distros do not support it. Generally, driverless printing is supported with CUPS 2.2.2 and cups-filters 1.12.0.

Driverless printing eliminates the need of a printer setup tool (like GNOME’s printer settings or system-config-printer) as cups-browsed and CUPS can auto-create print queues. For an application which prints, like LibreOffice nothing changes. LibreOffice only needs to list the available printers, list the options of the selected printer, and send a print job to the selected printer with the selected option settings.

Generally, all printing applications should auto-connect to an interface which allows them to print.
An interface which allows to print on CUPS would need not more access to localhost:631 and access to the domain socket of a system-installed CUPS (is currently /run/cups/cups.sock, you can find it running lpstat -H). In the CUPS snap I will assure that localhost:631 will work.
My question is now, what does the cups-control interface exactly allow?

This and all other interface security policy is located in the snapd source. For cups-control, see: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/cups_control.go

This interface primarily uses the ‘cups-client’ apparmor abstraction in /etc/apparmor.d/abstractions/cups-client.

It is understood that applications that can print need to have the corresponding interface connected that allows it. The problem is that applications that use libcups end up requiring access to the /run/cups/cups.socket. This socket allows much more than just printing though (especially on single user system where the user is in the lpadmin group), which is why the interface is set for manual connection. This topic is about adding a snap declaration to auto-connect this interface for the libreoffice snap upon install since there isn’t a way to graphically display to the user the need for connection as part of install or at runtime. I’ve already given my +1 on this, and @evan should now have enough information to vote with your new comments.

Ideally cups would offer a ‘printing-only’ socket. If this were a unix socket, we could create a new ‘cups-print’ interface to allow connecting to that socket that would be auto-connected. I suspect that the network printing you are referring to is actually printing only (unless you authenticate through the web interface) so in theory snaps would only need the ‘network’ interface (which is auto-connected) to connect to this port and print. Unfortunately, this is not enough for many applications, which is why applications like LibreOffice are plugging the cups-control interface.

@evan, are your questions answered?

Yes, I’m supportive of auto-connecting this. Thanks @till.kamppeter and @jdstrand for the background.

2 votes for, 0 against. Granting auto-connection. This is now live.