Inkscape autoconnect cups-control

There probably isn’t much surprise in this post :grinning:

related decision:

Related, but considering that Inkscape’s default is actually a page intended to be printed I think it is somewhat different. Inkscape can be used to make icons as well. But certainly has a large user base of people who use it for print media.

I +1 this considering that even chromium has the auto-connection and it is not its main concern.

+1 from me too, as it makes sense to be able to print your beautiful creations.

damn, so the interface prevents ugly creations from going through ?


This appears to contradict the position in my GIMP thread methinks? If this is approved because “chromium has the auto connection” then GIMP should be just as viable on the same premise, yet was denied. Alternatively to maintain consistent decision-making then if the GIMP decision stands for the reasons stated there then this request should also be denied IMO.

(note: I don’t mind which way this goes, just that the decisions are consistent. Either allow this and gimp’s request or deny both or use reasoning other than “well this other thing does it, so it must be fine”)


@diddledani is right and we are being inconsistent here wrt the gimp snap. I vote -1 for auto-connecting cups-control to inkscape since printing isn’t core functionality for the application (indeed, most of one’s beautiful or not so beautiful creations would typically be sent to a printing company) and it doesn’t need the ability to configure printing on the system. Manual connection makes sense to me. Contrast that to chromium where people fill out forms, etc and are constantly told to print the confirmation.

@sergiusens and @popey - do these comments affect your vote?

Until you can prompt the user on use, I think the criteria should be “would I ever reasonably print” not “is it core functionality.”

Also, I’ve never heard of someone printing from GEdit, but it was granted autoconnect without much discussion: Auto-connecting the cups-control interface for the gedit snap

If the concern is over configuration I think that two interfaces should be made, cups-user and cups-control, where today they’d be identical, it would allow for reducing permissions in the future as the capability is built.


The problem with “would I reasonably ever print” is that it would apply to anything that plugs cups-control and all snaps have elevated permissions. cups-control unfortunately grants access to the socket which on a typical single user system grants admin privileges for printer configuration, which is more than intended and surprising when the application only needs to print. There is already the ability to connect the interface at install time when using gnome-software/snap-store and a snap can detect if it has the ability to print and let the user know there is an extra step. Since we’ve added install prompts, these two have in the past been deemed sufficient for use cases such as gimp and inkscape. As for adding ‘cups-user’, we can’t really add that because we can’t easily take permissions away from a snap without causing regressions (some snap somewhere would use cups-user and really need cups-control; this is why we only have cups-control now).

I’m not sure if the Printing portal is available yet (perhaps @jamesh could comment), but that is already allowed via the desktop interface which is autoconnected. Perhaps inkscape can be made to use it instead? cupsd could also be modified for prompting/mediation, but in this case Portals is likely the path forward.

1 Like

The problem in general is that seems to be how it has been applied. Some of the applications that are currently auto-connecting cups-control:

  • Firefox
  • Libreoffice
  • Chromium
  • GEdit

So if today you want to change the requirement to apps who’s primary purpose is configuring printers I’d say it is too late or you need to remove permissions from a fair number of popular applications.

Also, I doubt most users are installing via the software center. They wouldn’t know how to go there to edit the connections. And those aren’t available in a GUI on any distro other than Ubuntu, so you can’t really consider it a solution.

There is a printing portal that is used automatically by the GTK 3 print API. IIRC Inkscape is still using GTK 2 though, so Inkscape would probably need to manually poke the portal API to make use of it.

It would certainly be possible for a future version of CUPS to e.g. perform polkit authentication: I was able to implement it for snapd’s HTTP over unix domain socket API, so CUPS could do the same. I don’t think anyone is working on this kind of thing though, or whether it is likely to be accepted upstream. It’d require a lot of careful thought to decide what permissions each part of the IPP/CUPS API should need though.

1 Like

I agree we’re being inconsistent and should fix that. I’m concerned that we say ‘no’ to common use cases such as printing, and end up with a poor user experience. Typically when sandboxing gets ‘in the way’ of doing normal expected activities “Let me just print this thing” it causes major user frustration.

This can lead to users to just reject the snap altogether (who would know that they need to run an obscure command or open the app store to fix this?) and this tarnishes their experience of snaps in general. A thousand paper cuts like this hurts the platform as a whole.

This reasoning leads to auto-connecting everything. We should auto-connect the things that make sense to auto-connect. I think people are forgetting that the thinking on auto-connection is evolving as we go along. It is totally surprising that a snap that needs to print is allowed to configure printers on the system. It should also be noted that cups has a pretty terrible security record so always auto-connecting cups-control could lead to privilege escalation if new vulnerabilities are found in cups.

We’ve actually been consistent at any given point in time: at first there were no install prompts, so we tended to grant auto-connect. Then, gnome-software/snap-store added installation prompts (and no, snap-store is not Ubuntu-only-- it is a snap. It may not be everywhere yet, but it isn’t Ubuntu-only) and it was decided that this was sufficient to no longer just give away cups-control to anyone who asked for it. We now apply that criteria when voting on things like the gimp and inkscape.

As for the papercut, IMO this is a problem with the snap, not the platform. Other platforms require that applications use very specific APIs for different things. Those platforms don’t have a ‘print’ access that also allows configuring printing on the system. Applications on other platforms must be adjusted for the platform. snapd does not impose an implementation on the developer-- the developer can use libcups, gtk2, gtk3, lp, whatever, but depending on what is chosen, snapd handles things differently. Today, right now, an application can use gtk3 and print via portals without needing a snap declaration for cups-control. If a publisher chooses to use something else, that’s fine, but it is up to the publisher to create a good user experience. It is easy enough to try to open the socket to see if it has access to cups and if not, tell the user to run a command or use gnome-software/snap-store to connect. There are many snaps that do this for a variety of interfaces. Really, a snap publisher should do this regardless of if a snap declaration was granted since an admin of the system might choose to disconnect the interface leaving non-admin users on the systems scratching their heads on why they can’t print.

I asked @sergiusens to comment, but haven’t heard back. Since this seems to be a point of contention, I’m asking all @reviewers to review all of this topic so we can come to a consensus and have clear voting standards on this interface. @niemeyer and @pedronis, can you weigh in as well?

I think having a programmatic way for a snap to be able to test if it has an interface connected, say with snapctl would go a long ways towards making this type of user experience easily implemented. Perhaps it is easy with cups specifically, but for other things it is not so easy for a snap to tell if it has access to something provided by an interface, or if the thing that the interface provides access to is just misbehaving.

My two cents: I’ve actually printed from all the applications with the interface automatically connected. I’ve never printed from gimp or inkscape, despite using them heavily. I typically export to another format and end up printing from evince (if at all, most of my work ends up online somewhere).

I agree with @ijohnson, though: it would be nice to have an easy way of determining if an interface isn’t connected or if permission is being denied for some other reason. Putting that functionality into snapctl seems to make sense, although until something like that exists the snap could probably track the state of connections on its own using interface hooks.

I’m a -1 on this, mostly based on my “have I ever printed from this” reasoning. However, I agree that it causes a UX issue that I’m not quite willing to blame completely on the snap itself: this story is rough without portals. That is, however, a reason to focus on portals (or another way to improve the handling of a missing interface connection), not a reason to compromise on snap security.

1 Like

snapctl supports this concept, but only during interface hooks. I’m not sure why that is:

$ snapctl get --plug :cups-control
error: error running snapctl: interface attributes can only be read during the execution of interface hooks

That said, one could write an interface hook to run the above and touch/rm a file to determine if the interface was connected. That is better than looking at a socket, but could be improved, certainly. Perhaps @pstolowski can comment on the current limitation.

If that is the case it is also important to apply that new thinking to all of the existing cases. So I don’t think arguing “we’ve changed” until you’ve applied that logic to Firefox. Which I doubt would actually happen. Politically, you can’t break printing in Firefox, so the policy becomes more political than practical at that point.

It is only installed by default on Ubuntu. Defaults matter. It is basically nowhere else, nobody uses it on other distros, and I’m skeptical to the number of users on Ubuntu vs. installing on the command line for snaps. I don’t think you can use that as an assumption or expectation that users can configure permissions using it. For a quick comparison you can look at how many distros snap-store is installed on versus Inkscape.

This is largely false. An application can use portals to print if they’re on Ubuntu 18.10 and have all the portals installed. They’re not in main in 18.04 and not even in 16.04, much less 14.04 and the other distros that snaps claim to support. Until portals are a dependency of snapd applications can’t depend on them being there, so we’re forced to deal with things like cups-control.

I think that anecdotes from developers are not a good way to judge what users use an application for. Upstreams have a much better idea. Nothing against your usage, it’s valid, but I think it’s important to not consider individual use-cases from a limited set of people. For instance, I’ve never printed from GEdit, doesn’t mean printing from it is an invalid use-case.

To summarize: there is no practical UI to connect interfaces; portals don’t work for most users; while I agree autoconnecting cups-control sucks it is all we have. If things get fixed in the future I’m happy to drop it then.

I agree that we can’t just up and start revoking already-granted auto-connections for fear of breaking users of that snap, but that seems about as political a decision as not wanting to break backwards compatibility in an API.

I’m indeed a developer inasmuch as I write software. However, I am not a gimp developer, nor am I an inkscape developer. I was offering my point of view (which was of course anecdotal) purely as a user of these pieces of software, not as a developer. Or are you saying my point if view is invalid because I happen to write software?

Your point of upstreams understanding how their software is used is a fine one, and one I don’t mean to argue. To be clear, no one is saying printing from inkscape is an invalid use-case. The question is whether the application would appear fundamentally broken without the functionality represented by the interface in question, thus necessitating the auto-connection. From my point of view, it would not.

Arguing that ‘cups-control’ is all we have is one thing, but arguing that auto-connecting cups-control is all we have is quite another and I disagree. auto-connection for cups-control is not a right. If it was, we would always auto-connect it. The question is whether or not inkscape should have it auto-connected. We have a voting procedure and a process which we are exercising to determine that.

In terms of consistency, we should strive for consistency between similarly scoped snaps, not all snaps. Inkscape is not a browser and comparing it to one to justify auto-connection is not apples to apples. Comparing it to gimp is apples to apples and if after our process for auto-connection is complete for inkscape, the vote is for auto-connecting cups-control, then we should reapply that new criteria to the gimp for consistency.