Classic confinement request for duf-utility

I’ve uploaded for review duf-utility to become a classic snap.

duf is a utility that displays avail/used diskspace, similiar to df. It requires access to the real mount table so it can retrieve information about attached mounts & devices. The strict confinement prevents that as it presents duf a virtual /proc/self/mountinfo (even with the mount-observe interface enabled), which causes various issues.

Thank you for considering this!
-Chris

Can you elaborate on this? snapd doesn’t modify this file at all, but the strict snap is put into another mount namespace which is not the root mount namespace, so the mounts may appear differently (and you may see additional mounts which are specific to the strict snap’s mount namespace), but otherwise you should be able to strip the /var/lib/snapd/hostfs off of any snap mount entries you see as that corresponds to the root mount namespace

Your analysis pretty much sums it up: snapd does only provide a virtual mountinfo , so one would have to modify duf’s source code and add a bunch of special cases left and right, just to make it show accurate information when ran under snap’s namespace, like:

  • detect virtual snapd entries
  • strip /var/lib/snapd/hostfs (and other design specific implementations)

Programs shouldn’t have to be adapted just to make them work in a snap environment.

1 Like

Is there no other standardised way this information is exposed on Linux which would work when inside a snap or not?

I’ve checked the source of coreutils, df and even a few other tools, and they all access /proc/self/mountinfo to retrieve the mount data.

There are other legacy/deprecated methods to access this information, but they either only give you a limited set of data and/or suffer from the same problem within a namespace.

The problem here is that within the namespace the information you retrieve is technically accurate indeed, but as a user of df or duf I’m interested in the free space of my actual hardware, not some abstraction layer above it.

Can we please find a solution for this? This has been blocking our release for a week now, and I’m getting more and more bug reports from confused Ubuntu/snap users. If this can’t be resolved, I’ll have to delete the snap again, because it’s becoming a support nightmare :frowning:

Can you give an example of what sort of entries in /proc/self/mountinfo from within a strictly confined snap are producing incorrect information from df, etc. and what those entries look like outside confinement?

Unfortunately, even with classic confinement we cannot guarantee that these mounts won’t appear some day with a new snapd release because features we want to add to classic snaps (such as the experimental parallel snap instances or having content interfaces work with classic snaps) require entering into a new mount namespace, so if your application really cannot operate with the additional mounts inside the mount namespace then it may not be a good fit for snap packaging. You can test this yourself by making your snap classically confined, then enabling parallel instances and trying to install another instance of the snap.

We could some day introduce some form of proxying such that when an application tries to read /proc/self/mountinfo from within the sandbox and the snap has a special interface connected, snapd will intercept this read and replace the real output with whatever the host’s /proc/self/mountinfo is, but that would take a fair bit of work we don’t have roadmapped currently.

1 Like

ping @muesli - this request cannot proceed without the requested information. Thanks.

I’ve actually went ahead and tried to implement some compatibility layer in duf for snap environments, but it’s a considerate amount of work and it will probably take me several weeks to find the time to finish this up.

In the meantime, I would still appreciate it if we could switch this to the classic confinement for the time being. This would ensure duf works out of the box right now and would spare a bunch of users (currently >1.6k on snap, wow) the disappointment.

Can you give an example of what sort of entries in /proc/self/mountinfo from within a strictly confined snap are producing incorrect information from df, etc. and what those entries look like outside confinement?

All the entries duf is interested in are within the /var/lib/snapd/hostfs/ namespace. Everything outside of that namespace is irrelevant to duf or its users.

As an example, here’s an entry you would see outside of snap:
62 1 0:30 / / rw,relatime shared:1 - btrfs /dev/mapper/bender-root rw,ssd,space_cache,subvolid=5,subvol=/

Here’s the same entry within the confinement:
1333 1332 0:43 / /var/lib/snapd/hostfs rw,relatime master:1 - btrfs /dev/mapper/bender-root rw,ssd,space_cache,subvolid=5,subvol=/

1 Like

ping @alexmurray @ijohnson - see my message / renewed request from 17d ago: I’d still appreciate if we could switch this to the classic confinement for now.

@muesli I appreciate your point of view on this but at this stage, referring to the process for classic confinement requests I don’t believe duf-utility fits into one of the existing categories for classic confinement. Whilst we have a debug tools entry there, this is more related to actual debuggers and similar, not observational tools like this. So at this stage, I don’t think it is appropriate to grant classic confinement for duf-utility.

Understood. Sadly that leaves me with no other option, but to remove the duf snap from the store again, as I can’t currently support it. There’s a duf package in Debian unstable, so hopefully it finds its way into Ubuntu again eventually.

Thanks, everyone.