Request classic confinement for zffmount

store-requests
#1

Hi there,

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.

#2

Hi @ph0llux!

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.

#3

Hi @emitorino,

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:

  1. the mountpoint is determined by the user, not by me. That happens with an argument (-m).
  2. 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. :smile: ). 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 :slight_smile: ).

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. :wink:

#4

@ph0llux hey,

Apologize again for the long delay in answering, this request got lost in our review queue.

The mount_control interface allows allow_root for fuse, have you explored if this can help to support your use case?

Thatā€™s indeed a very valid point, since as per our process for granting classic confinement, thatā€™s a requirement.

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?

Thanks!

#5

@ph0llux ping, can you please provide the requested information?

#6

Hi @emitorino,

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:

name: zffmount
adopt-info: zffmount
summary: Tool to fuse-mount zff files.
description: |
<omitted> base: core20
confinement: strict
parts:
zffmount:
build-packages: [ gcc, fuse, libfuse-dev, pkg-config ]
stage-packages: [ fuse ]
plugin: rust
source: .
override-pull: |
snapcraftctl pull
VERSION="$(git describe --tags --abbrev=0)"
[ -n ā€œ$(echo $VERSION)ā€ ] && GRADE=stable
snapcraftctl set-version ā€œ$VERSIONā€
snapcraftctl set-grade ā€œ$GRADEā€
override-stage: |
snapcraftctl stage
chmod u+s bin/fusermount
plugs:
mntctl:
interface: mount-control
namespace: host
mount:
- what: /**
where: /**
type: [ fuse ]
options: [ rw, async, ro ]
apps:
zffmount:
command: bin/zffmount
plugs: [mntctl, fuse-support]
architectures:
- build-on: [ amd64 ]

But it doesnā€™t work.

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. :confused:

Thatā€™s indeed a very valid point, since as per our process for granting classic confinement, thatā€™s a requirement.

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.

Thanks,
ph0llux

#7

Hi ph0llux,

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?

#8

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.

1 Like
#9

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.

#10

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.