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:
Programs shouldn’t have to be adapted just to make them work in a snap environment.
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 
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.