I would like to leverage snapcraft to deploy plugins for an application which is not released as a snap. In the process I have found that this does work but I have ran into a few issues. In order for it to dynamically load the plugin the LD_LIBRARY_PATH must contain the path to the snap package libraries. which is not ideal because this it cause issues with running things on the host machine. The next option I believe is to update the rpath for the libraries and executable within the my snap package. I noticed that there is a part patchelf used for classic confinement apps and would like to know if this could be used for non-classic snap package and if that would be recommended to solve the issue? Also I guess I could request classic confinement for my snap package. @sergiusens, @kyrofa
@sergiusens is there a way to enable that rpath logic used for classic snaps when building a strict snap?
Interesting idea, should be a simple feature to add considering it just needs to do the opposite of “no-patchelf”
We toyed with the idea of doing it by default for everything in the past. It seems more and more relevant as we gain interfaces like personal-files and system-files. Think that’d be overly disruptive?
If the aim is to distribute a shared library that will be loaded by an unconfined process, it doesn’t make a lot of sense to use strict confinement, since you’ve immediately got code execution outside of the sandbox.
It’s not clear to me this is a good fit for snaps, but if it is it may as well use classic confinement. That’s effectively what it is from a security stand point, and it has to deal with the same rpath issues as a classic snap.
I also wanted to provided some additional information about this. The snap package being release is a visualization tool that supports communication via protobuf for robotic simulation. In our motion planning environment software it has a visualization interface for plotting markers, trajectories, etc. supporting loading these as plugins. The idea of releasing the implementation with the snap package was to avoid adding additional dependencies to the motion planning software. After the plugin is loaded it communications with the visualization tool via protobuf.
Note that this is only one function of a larger snap. Note also that classic requires manual review.
After further consideration, I have decided to transfer the plugin to the other repository which needs to load it. This then only communicates with the snap through protobuf and solve the dynamic loading issues. Though I still like the idea of leveraging snaps to deploy plugins and look forward to further discussion of setting the RPATH for snaps with strict confinement.
@Levi-Armstrong I think that use-case is absolutely valid, and snapcraft really requires this functionality for the plugin-style sharing made possible by the content interface between snaps. I’ve proposed this new feature here: