Inkscape autoconnect cups-control


Not really, an API doesn’t choose which applications can use it or not. Here we’d be avoiding breaking applications that have the phone number of management.

You’re right, it doesn’t matter whether any of us are developers are not, I was incorrect to state that. There shouldn’t be any anecdotes involved in voting. It shouldn’t be about personal experience but about user experiences.

I’d say it is whether a project would feel like they need to put on the download page “here’s how snaps are broken” with a discussion of it. It is at that level for Inkscape. Inkscape Snap Download Page.

I would argue given the current state of the UI controls it either auto-connects or it doesn’t exist. Frankly, I was surprised I had to make this forum post I figured the issue was something wrong with my snap. It didn’t occur to me that I can autoconnect to X11 but not CUPS.

I would support autoconnecting cups-control for The GIMP as well. I think you’d have a hard time defining which apps are comparable to others.


We autoconnect desktop / x11 which we know have shortcomings from a confinement point of view, but we do this for convenience / usability until better interfaces (security-wise) are ready - why not apply the same logic for cups-control but with a strong encouragement (documentation-wise) to avoid it and instead promote portals as the preferred mechanism (for apps which can support it) and then take @jamesh idea to add polkit authentication to CUPS or similar so we can feel more confident in granting cups-control for situations like this?


Is this anecdotal? I have never printed from chromium or firefox but print from evince instead (yes, anecdotal).


General hooks (configure, refresh, install) run under their own confinement, do they not? Not sure about the interface hook, but it would need to run under the confinement of the connecting plug specific to the application for the snapctl check to be a good one.


Firefox and chrome have an internal pdf viewer and don’t rely on evince/some other mime handler. The same appears to be true for firefox with general printing.


Because with desktop/x11 most applications completely fail to work if these aren’t connected. With printing, most applications typically can work fine without it until one tries to print but even then application is in a position to guide the user. To me, we should not change the base declaration to auto-connect cups-control, but we should have a consistent voting policy on when to grant auto-connection.

I’m all for having documentation for encouraging people to use blessed APIs. TBH, I’m a bit surprised that polkit wasn’t upstreamed in cupsd already. There is cups-pk-helper, but AIUI, that is about exposing non-cups DBus APIs and using that service as a proxy so the application doesn’t have to use the cups socket directly. Another option would be to use a proxy service. I suspect that this could be fairly simple since cups has a rather extensive auth and ACL mechanism. It could be that a service snapd provides that runs as non-root and non-admin (from a cupsd PoV) listens on a socket. That socket is bind mounted into the the snap’s runtime at the normal cupsd socket location. Snaps connect to it and then the service proxies everything between the snap and the real cupsd socket. Because the user the proxy runs under has no special permissions for configuring printers, etc, it is only allowed to print. We would need another snapd interface to trigger this bind mount behavior whereas cups-control would not trigger it.