Classic confinement request: snippetpixie


#1

Hi,

As confirmed by @jamesh it looks like the desktop-legacy and other interfaces do not allow enough access to the AT-SPI accessibility framework for Snippet Pixie to be able to work with most applications while strictly confined.

For this reason I humbly request that the snippetpixie snap be granted use of classic confinement.


#2

The requirements are understood in that this application is meant to drive/gather data from applications via the accessibility framework. There are no interfaces for this currently and it isn’t clear if we want to introduce them (the feature would need investigating, but I doubt that we would be able to mediate this finely such that ‘this snap can drive that application via accessibility’ and not having that would grant total control of the user’s session). @pedronis, fyi in case you didn’t see this or the other conversation.

@advocacy - can you perform the vetting?


#3

@advocacy - ping, can you please perform the vetting?


#4

Vetting done, +1 to classic for snippetpixie.


#5

Granted use of classic. This is now live.

Note, your snap is currently specifies plus with classic confinement, which is currently unsupported. Please remove any plugs and slots, reupload and it should pass automated review.


#6

Awesome, thanks folks!


#7

@jdstrand I just tried to trigger a new build (#25 via build.snapcraft.io) and the new version has failed due to the previous version still being in manual review?


#8

Ok, I manually rejected #24, and #25 automatically fails because it’s using classic confinement with content level plugs, which I didn’t expect (thought the warning above was related to app level plugs entries).

I guess I have some researching to do as to how to properly integrate classic confined snap with GTK desktop!


#9

I came across similar issues trying to snap Emacs with classic confinement - https://forum.snapcraft.io/t/problems-trying-to-snap-emacs - you should remove the plugs section.


#10

Thank you @alexmurray!

With your updated note in that thread about building desktop-gnome-platform but making sure to not create the gnome-platform directory by removing the build override, bin/desktop-launch now does its thing without complaint.

However, now I get a segfault (core dump), which I didn’t get when strict confined.

Seems to be related to anything desktop, so snippetpixie’s command line options --version, --status and --import are working, but as soon as I attempt --start which needs to access desktop APIs, or of course try and see the window, segfault.

Does anyone have any advice on where to look for the problem? (sorry if the answer is very obvious, I’m new to Linux development)


#11

Does the same thing occur if you do not use bin/desktop-launch to launch the application?
You can try running it under the GDB debugger to see if this shows where the crash occurs and hence might give you an idea of why:

 snap run --gdb snippetpixie

#12

Thanks for the suggestions @alexmurray.

I found snap run --gdb myself actually, with that found the general area where the problem is, and along with a bit of gorilla debugging know exactly what’s failing.

I can circumvent that bit of code to get a mostly working app, just now need to circle back and find a fix for the bit I’ve skipped, I’ll work it out, eventually!