I would like to provide a snap package for my application zffmount.
Zffmount allows mounting and deploying dumps from zff containers (zff is a forensic file format, see https://zff.dev for additional information).
It creates an overlay filesystem and mounts it via FUSE to the path specified by the user. Subsequently, the objects located within the zff container are mounted as an object-specific file system (also via FUSE) within the overlay file system (nested mount).
The user can then use external programs to examine the mounted dumps.
For this process, among other things, user_allow_other is needed and fusermount is relied upon.
If I understand the corresponding github comment correctly, there are currently too many restrictions with the interface fuse-support that do not allow the above.
The tool is open source and the code accordingly available on github for analysis.
I am not sure how detailed you need the description of the program as this is my first classic request. Please let me know if you need more information.
Apologize for the delay. Is it possible for zffmount to set the mountpoint to snap-specific writable directories (i.e. $SNAP_USER_DATA, $SNAP_USER_COMMON, $SNAP_DATA or $SNAP_COMMON) instead?
In general for a snap to be granted classic confinement, they need to fall under any of the supported categories. In this case I believe we should work towards allowing zffmount to work under strict confinement and thus enjoy the benefits of an stable runtime environment.
No problem - I had considered sending a “push”, but thought it might take longer with classic requests.
Thank you for spending your time to answer my request.
It is theoretically possible to set the mountpoint to one of the paths you mentioned but:
the mountpoint is determined by the user, not by me. That happens with an argument (-m).
unfortunately this would not solve the basic problem. zffmount needs allow_root or user_allow_other to allow a nested mount (user_allow_other would provide a maximum amount of flexibility here, but if that’s what it comes down to, I would of course let myself be traded down to allow_root. ). This is (to my knowledge) unfortunately not supported by the fuse-control snap interface (or any other snap interface I know of - but if there is one, I am of course very open to suggestions ).
I’ll elaborate a bit more to make the actual problem more understandable:
The tool is in fact used to allow the user to “mount” files in this file format. If the tool were to simply mount such files via FUSE in order to then process them myself, I would immediately agree with you and be able to restrict myself to one of the paths mentioned above. However, since the purpose of the program is to allow the user to mount to the path of their choice, your suggestion unfortunately directly counters the actual purpose of the program.
With this we have described the first problem.
The second problem: You can consider zff as a kind of container system, which contains a different set of subcontainers (internally called objects). zffmount creates an overlay filesystem and mounts it via FUSE. Into this overlay file system, the respective objects are then mounted into a folder located in the overlay file system with the appropriate object file system for the object type via FUSE. Let’s say we have a zff container with three objects and I would mount it to /tmp/mount using zffmount, the folder structure would look like this:
|-- /tmp
|-- mount/ (overlay filesystem)
|-- object_01 (content of the first object with appropriate filesystem)
|-- object_02 (content of the second object with appropriate filesystem)
|-- object_03 (content of the third object with appropriate filesystem)
From my perspective, there is a gap here between what interfaces are offered and what is/will be approved for classic mode. I don’t see zffmount falling into either the supported or unsupported category of the classic review process right now. But of course that’s just my point of view.
Still, I see zffmount is successfully published under strict confinement, and it is indeed actively consumed from the snap store. So can we say classic is not needed any more?
Thank you for your response and the reminder (I had already started with an answer, but wanted to test further to make sure that mount_control is not an option - I apologize for my late response.).
I’ve been trying for many hours now to see if I could get it to work with mount_control, but I just didn’t have any luck. It seems to me that even with this it is not possible to get a nested mount.
To test mount_control, I’ve modified my appropriate snapcraft.yaml to this:
Still, I see zffmount is successfully published under strict confinement, and it is indeed actively consumed from the snap store. So can we say classic is not needed any more?
However, the published zffmount package under strict confinement is not working as expected.
There are programs that are exclusively designed to deliver content from specific file formats using FUSE.
For such programs, a separate category would be really desirable.
zffmount is such a program.
We would like to see zffmount in the store and working correctly but despite the difficulties you are facing with confinement I don’t think that an exception or new category is the right approach here.
Can I suggest re-asking the question and explaining use-case and troubles you’re having with mount_control under the snapd forum topic to see if anyone there has suggestions?
Sure. I’ll create a minimal example and try to use it to identify the problems with mount_control (I’ll open a new thread for this in the subforum you mentioned).
I’ll come back to this thread here if indeed the problems simply can’t be solved.
I ve a issue while attempting to package my application. I followed the Snapcraft documentation meticulously and configured my snapcraft.yaml file according to the guidelines. I tried to build my Snap package using the ‘snapcraft’ command, it threw an unexpected error message stating that it couldn’t find a specific dependency, even though it was clearly listed in my YAML file. I verify the dependency was installed, and even sought help from the community, but the issue remained unresolved.
hello @fredcason639, may I suggest that you start a new topic in the snapcraft category to request this help. You may also need to supply some more details such as your YAML and specific errors you’ve encountered.
I have now dealt intensively with mount-control and identified the problem - unfortunately mount-control is not an option.
mount-control only gives me the option of using mount.* (in this case e.g. the mount.fuse3 command). Unfortunately, the library that zffmount uses (and indeed all other Rust libraries that are well maintained to use FUSE) using fusermount(3) in background (which is the current default way to deal with FUSE).
However, fusermount(3) seems not to be covered by mount-control, but only by the fuse-support interface.
However, the tool (zffmount) only makes sense if I can perform a FUSE mount anywhere in the system and not just within the snap directories - so the fuse-support interface only is not an option.
I have rewritten the whole tool (zffmount) again and also removed the nested mount, so that my allow_other or allow_root is no longer required - but unfortunately this does not solve the basic problem.
I think I’m running into similar problems as restic would (which is classic and can only FUSE via fusermount).
The zff format is used to store data for forensic analyses.
In principle, it is a form of a backup - plus metadata.
As far as I read from this post here, backup tools are a way to perform a classic confinement…?
Both posts you linked are 5y old, at that time backup tools were actually still in the supported category on the Process for reviewing classic confinement snaps page… very shortly after these posts the system-backup interface has been created and in turn this set of applications has been removed from the supported list, since the functionality is now covered by that interface…
While i indeed doubt that system-backup would help your specific case at all, these posts are not really relevant anymore… (and pointing to other old posts will likely not help either, the list on the process page is the mandatory source for granting/denying classic)
Hi,
Thank you for your response.
You are absolutely right. The thread is already 5 years old.
However, the tool would still run into the same problem as zffmount without classic support: what I want to show is that zffmount is potentially not the only tool with this problem.
zffmount is neither supported nor unsupported in the classic categorization.
However, the following is listed under “Criteria”:
“access to resources not yet supported by snapd and where the requirement is clearly understood to be supportable by snapd. This may result in temporarily granting classic until snapd supports the use case in strict mode”
(Yes, I read the note underneath…which doesn’t rule it in or out )
Therefore, I would like to ask for a time limited exception, so that a review can take place again after an implementation of a fuse-control interface or something like that is done, which has the appropriate abilities…?
I would also prefer to see my tool in strict confiment, I can definitely see the security advantages here - but at the moment it is not feasible due to the lack of a suitable interface.
). This is (to my knowledge) unfortunately not supported by the 
).
