With permission of the upstream developer, I created a snap for Buku bookmark manager. It’s pushed to the store and currently awaiting review.
This is my first crack at snapping anything, so apologies if I’ve got this wrong, but my understanding is that this snap would need to be ‘classic’, owing to the necessity to access the web browser and text editor on the host.
I’ve also just become aware of the snapcrafters repository, whilst browsing this forum. Would it be more appropriate for this snap to be maintained there? I contacted the upstream developer through raising an issue on the project’s Github repo, where he said he does not maintain any downstream packages himself, but would have no objections to me maintaining the project’s snap package.
Since making this post last week, I received a notification from someone reviewing for the snap store, who asked me to post a request for classic confinement in here. So, bumping it to keep it on the radar. Thanks.
@aninstanceofdan - it sounds like your snap wants to edit bookmark files in hidden or snap-specific data files for webbrowers. Today, the would require classic confinement, yes. Soon portals will be enabled and allow for opening arbitrary files. What mechanism does your snap use for choosing files?
@jdstrand Buku is a CLI bookmark manager, which allows for creation, editing, search and storage of website URLs in a SQLite3 database. The records may be added through the CLI or keyboard shortcut.
When a bookmark entry is selected, the app opens that URL in system default web browser. That, I think, is where the classic confinement would be necessary.
If your snap uses xdg-open <url> (which is the freedesktop.org standard way to open the browser), then Buku will be able to open the system browser. This is because in the runtime of your snap, xdg-open talks over DBus to snapd’s userd to launch the browser on behalf of the application. Does this resolve the need for classic?
I haven’t examined the code to determine what method is used to open the browser (I’d need to look into that). I do know that when I tested running the snap without classic, it fails.
I just tried creating as strict again, to test: It also throws errors such as when the app uses python’s urllib3, e.g.
<urllib3.connection.VerifiedHTTPSConnection object at 0x7f0c82a83588>
Is it possible to create the sqlite file in the user’s home directory (or elsewhere on the system) through the snap using strict? Part of the attraction of Buku (at least for me) is to be able to have the url database hosted in a synced directory (in my case, Nextcloud). When testing using strict, I attempted a workaround by symlinking the database file into the Snap’s /.local/share/buku, but get permission errors (which I’d expected, since that makes perfect sense from a security standpoint, but thought I’d try it out anyway!).
I suspect the https issue might be because the snap doesn’t ‘stage-packages’ the ca-certificates package. This is just a guess.
If the snaps uses ‘plugs: [home]’, then it would be able to access non-hidden files and directories, for example, ~/Nextcloud/buku.
For testing purposes, you could set up the symlink the other way. Move the file into the snap’s .local/share/buku and then create a symlink from ~/.local/share/buku to ~/snap/buku/…/.local/share/buku. Do note that we set $HOME to be snap specific so that snaps can work independently of system installed software (so that they can’t interfere with them). As such, be careful if you setup the symlink and have the snap installed and buku installed from source/etc if the versions aren’t the same.
Thank you, making progress on this. Using the ‘home’ plug was successful in allowing me to symlink the sqlite3 database from host $HOME to snap $HOME.
I also resolved the urllib3 issue by adding the ‘network’ plug (I’d overlooked that this plug is required to get network within a non-classic snap).
The only remaining outstanding issue is that the app still cannot open the system web browser. I had a look at the app code; he’s using python’s webbrowser package to control the browser, using the ‘get’ method, which returns a controller for the default browser as set in the user’s environment (on the host).
Now I’ve had a chance to take a closer look at the code; the python webbrowser library (which buku uses) does indeed call xdg-open, so I’m not sure why it it works fine in classic, but not in strict.
The other thing that the app needs access to is the system text editor (it’s used to edit descriptions of the bookmarks, etc).
FYI, you may be interested in the snappy-debug snap. You install it, run ‘sudo snappy-debug.security scanlog’ in on terminal, then exercise your application in another and it will suggest things to you based on the confinement violations.
As for xdg-open in particular, when classic, the snap uses the host’s filesystem to launch xdg-open. In strict or devmode, your snap is running within a mount namespace with the core snap as its runtime. The core snap has an xdg-open in it that your snap would use, but today, it doesn’t support files (only http/https and mailto links). In snapd 2.32 we’ve adjust xdg-open for files and directories. 2.32 is scheduled to be released soon. You might try ‘sudo snap refresh core --edge’ and it might start working for you (I’m not sure if what’s in edge has this functionality yet, but it may).
Thank you for the info, much appreciated. I’ll certainly install and run the debug snap on this when I’ve got a moment and see what it throws up.
Regarding xdg-open, buku is just opening http/https URL links through Python’s webbrowser library (calling xdg-open), so it’s strange that it’s not working on strict. Hopefully the debug will cast some light (I guess buku could calling other system resources that I didn’t spot when I checked his code for the web browser stuff).
Thanks for asking! No not yet, I was planning to run the debug snap, then stuff came up so I put this on the back burner. I’ll do the debug shortly and see what it turns up. As @evan mentions below, it would need access to the system editor (or at least, an editor).
Thanks, I’m just waiting for further developments on whether or not this qualifies for ‘classic’ status. I haven’t found anything significant to add during my attempts at debugging.
I understood from above that the call to $EDITOR would require classic status. If above is correct but you’d prefer the app code to be refactored in some way to negate that requirement, then I’ll withdraw this request for now thanks, since the developer has no interest in snapping this himself and I don’t feel it’d be appropriate to fork his project for the sake of adding an additional distribution channel.
