I would like to request classic confinement for the volsung geothermal reservoir simulation package.
Volsung is a commercial product. The package consists of multiple applications which need to interact correctly with each other. Further users need to write little python helper scripts for customized data processing etc. Since these helper scripts live outside of the sandbox environment I have extreme problems to get this working using the “strict” confinement.
I find it rather strange that there’s no end-user option to allow “classic” confinement on an arbitrary snap - maybe this is a feature that the snap team should think about adding in?
where do the python helper scripts usually reside in a non-snap installation of volsung?
And of course the follow-up question: would it be unfeasible to get the user to store these scripts into a directory that a snap (under strict confinement) could access?
unfortunately the situtation is very complex. We make use of PEST (https://pesthomepage.org/) to facilitate inverse modelling. For this we require that the geothermal model needs to be cloned to a lot of “agent” nodes automatically; the python scripts must hence form part of geothermal model project and we have no control over the locations of the project folders.
Further the user must do their own analysis (results of which are being fed back into our Volsung simulators). We can not anticipate what kind of analysis they will do and what python (or other) scripts and libraries they require for this, so it’s hard to provide them with good options unless we allow them to execute arbitrary code.
In addition the simulation package encompasses a lot of different hardware and system requirements (network drives, desktop application access, etc). So far I have managed to squeeze these into the “strict” requirements by opening up the corresponding confinements; however I had to make a lot of functional sacrifices which I am not too happy about. Switching to “classic” confinement would solve all these issues for us and would allow the user full functionality of the software - and given that they actually pay a lot of money per license seat it would be only fair for them to have this functionality.
Snaps tick sooooo many good boxes for us and so far the only drawback that I have found are the limitations imposed by the strict confinement.
I understand you cannot anticipate the locations a user might chose to write scripts or to do their own analysis, but on the other side there are typical locations for users files and folders that your snap could access by plugging some interfaces like home, personal-files, system-files and even removable-media if needed meanwhile staying under strict confinement. Did you try some of those already?
You can use snappy-debug while troubleshooting . It will suggest interfaces based on the behavior it observes on your snap.
Isn’t the main problem with scripts that they call on executables? So I can’t anticipate which executables/libraries they will call on?
If the executables are placed within
SNAP_USER_COMMON then a strictly confined snap should be able to read and execute them - would it be possible to document this as a workflow so that this snap could then work under strict confinement?
I resolved this by
- listing python as a dependency in the snap
- installing a minimum requirement of python packages (like pandas, vtk etc) in the snap
- installing further scripts specific to Volsung in the snap
The users can now execute their custom python scripts, provided they only make use of the python packages we provide in the default installation. This is not ideal since it restricts them in their choice but our solution will be that they can contact us if they require more python packages. So we will accept this as a workable solution.
Unfortunately we have now run into further problems with a new library (libs2n) which has code in its execstack. We will work on this issue separately; maybe we will get this resolved with the store team so we can keep Volsung in strict confinement. However I must say these issues seem to add up and I would really like to see an end-user choice regarding what confinement levels they are happy with instead of making this decision by committee here.
That is great to hear you got it working - one clarification, classic confinement is not a decision by committee - it is a well documented process with relatively clear guidelines for what meets the requirements for classic confinement requests. If a snap meets these requirements and fits within one of the existing defined categories, we will grant classic confinement. If not, and a case can be made that perhaps a new category should exist then we can expand the guidelines with consultation with a snap architect like @pedronis. However, not all applications fit well within the snap model so there are something things that whilst they could work with classic confinement, this is not able to be granted.