ncdu is a utility that reads drive volumes and displays the utilisation. Using confinement works for the systems with one drive and external storage but extra drives are not accessible. I’ve tried different configurations building the snap package read all drives but only the classic confinement works as the software is intended.
Please consider this request.
hey @faramirza,
Which interfaces did you try already with no success? removable-media covers /media, /run/media and /mnt. I believe you might also need mount-observe.
Running snappy-debug can help you identify other interfaces needed.
You might wanna check the https://snapcraft.io/duf-utility and related discussions such as Alias duf on duf-utililty & auto connection and Classic confinement request for duf-utility.
@emitorino When I run snappy-dug, no errors are displayed when I get the error I want to fix.
Error: could not open /var/lib/snapd/void
This happens when I’m trying to execute the application on an extra HDD that is not a USB.
/dev/mapper/sda /Data ext4 defaults 0 0
Here is the plugs that was tried and failed:
plugs:
- home
- removable-media
- mount-observe
- system-backup
The previous developer also tried in vain to get approval here:
Interface approval for ncdu snap
Is the purpose of classic confinement not for application not able to use strict confinement?
The errors I do see in Snappy-debug are:
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/.java/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/.java/ (read)
Suggestions:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
- add ‘personal-files (…the-personal-files-interface for acceptance criteria)’ to ‘plugs’
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/.synaptic/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/.synaptic/ (read)
Suggestions:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
- add ‘personal-files (see …/the-personal-files-interface for acceptance criteria)’ to ‘plugs’
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/hw-probe/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/hw-probe/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/remmina/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/remmina/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/certbot/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/certbot/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/grex/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/grex/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/fwupd/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/fwupd/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/nmap/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/nmap/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/htop/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/htop/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:17
Log: apparmor=“DENIED” operation=“open” profile=“snap.ncdu.ncdu” name="/root/snap/multipass/" pid=23236 comm=“ncdu” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
File: /root/snap/multipass/ (read)
Suggestion:
- adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
= AppArmor =
Time: Jul 19 08:11:45
Log: apparmor=“DENIED” operation=“capable” profile=“snap.ncdu.ncdu” pid=23393 comm=“ncdu” capability=2 capname=“dac_read_search”
Capability: dac_read_search
Suggestions:
- adjust program to not require ‘CAP_DAC_READ_SEARCH’ (see ‘man 7 capabilities’)
- add one of ‘system-backup’ to ‘plugs’
- do nothing if program otherwise works properly
= AppArmor =
Time: Jul 19 08:11:45
Log: apparmor=“DENIED” operation=“capable” profile=“snap.ncdu.ncdu” pid=23393 comm=“ncdu” capability=1 capname=“dac_override”
Capability: dac_override
Suggestions:
- adjust program to not require ‘CAP_DAC_OVERRIDE’ (see ‘man 7 capabilities’)
- add one of ‘log-observe’ to ‘plugs’
- do nothing if program otherwise works properly
I’ve reverted the snapcraft.yml to use strict confinement again but I cannot release as the builds are automatically rejected.
@faramirza the latest revision uploaded to the store still has classic confinement specified:
confinement: classic
That’s why it is still automatically rejected. You need to update that section to be strict instead.
Did you fix the denials shared in your earlier comment?
Oops! Thanks for that. I forgot to change the yml from my local version. I’ve built a new release. I’m getting the error below:
What is /var/lib/snapd/void about?
This cause no error while running snappy-debug
Is your snap trying to open all the paths in LD_LIBRARY_PATH? /var/lib/snapd/void is added to LD_LIBRARY_PATH for snaps to ensure that it is not empty so I assume this is where that is coming from?
@alexmurray This error only pops up when I run ncdu from a drive other than the one containing /.
In my fstab:
/dev/mapper/vgmint-root / ext4 errors=remount-ro 0
/dev/mapper/sda /Data ext4 defaults 0 0
ncdu works from / but not from /Data
ncdu is mostly used on headless servers and it would be imperative to see utilisation of all drives, as the software is intended.
Can you please clarify what you mean by “when I run ncdu from a drive other than the one containing /” - are you running ncdu against a particular path for it to analyse or are you placing the executable within this other path and then executing it? I would like to try and reproduce this error to help debug it so if you can help clarify how exactly to reproduce it that would be great. Thanks.
@alexmurray Yes. The first option. I’m executing ncdu, installed with snap, from a path that is not found in the primary drive.
What I’ve found since is that if I browse to /var/lib/snapd/hostfs I can access all the paths from all the drives in the systems.
@faramirza Indeed, the entire host filesystem is mounted inside /var/lib/snapd/hostfs but in general a snap would need to plug system-backup to be able to read from this - so one option might be to translate a user requested path into the equivalent path under /var/lib/snapd/hostfs and show results from this instead.
Will it be possible to allow classic confinement as requested originally? The code is not currently aware if it is running inside a confined environment and the developer will not improve on that anytime soon. Snap might not be ideally suited from this package and if classic confinement not approved it would be best to remove it as it is not functioning as it should when used on hosts with multiple drives.
https://code.blicky.net/yorhel/ncdu/issues/175#issuecomment-968
@faramirza - the Process for reviewing classic confinement snaps is pretty clear - so if you believe ncdu fits within one of the existing supported categories for classic confinement then please make a case for that here and we can discuss. Also if it does not fit within one of the existing categories but you believe that there should be a new category created then this can also be discussed with a snap architect like @pedronis. Thanks.
@alexmurray What would suffice as a adequate technical explanation why the software needs classic confinement? This and other related threads all point out that the ncdu or related utilities do not work correctly when run from snap.
@faramirza just because something doesn’t work under strict confinement, it doesn’t meant that therefore the next step is to switch it to classic confinement. It could be there are other options for making the snap work correctly under strict confinement, and that these need to be explored. Users expect snaps to be confined by default and so if a snap is not (ie it has classic confinement) then there should be good reasons for this as it essentially allows the snap publisher unfettered access to the user’s machine. We therefore want to be confident when we grant classic confinement that this is strictly necessary and that we have some trust in the publisher of the snap. As such we expect publishers that wish to pursue classic confinement to make a strong and specific case for why this is necessary and to outline how it fits within the current process for assessing classic confinement requests as I linked to earlier.
@alexmurray I agree and I’m willing to spend more time to get this working as I’d like to be part of the community and learn about snap packages.
Here are previous attempts to make ncdu work as a snap:
Interface approval for ncdu snap Attempted to make it work with strict confinement. It kinda works but only in primary drive and USB.
Classic confinement for ncdu Here it was suggested that ncdu be made aware that it is running inside a snap. The developer is not going to do that as previously stated in this thread. Anything more than this would require the application to be changed. The previous publisher gave up on getting this to work correctly.
The conversation should be how to allow a tool like ncdu and the like to still function normally.
Since snappy-debug do not show anything when ncdu fails I’m stuck in providing more usable feedback.
Hey @faramirza,
Did you make any progress on making ncdu work as expected while staying under strict confinement? I ask since unfortunately this request does not meet the requirements for granting classic confinement as already explained. And I see the snap is still published and is plugging system-backup so maybe you could access the desired files via var/lib/snapd/hostfs?
Let us know so we can properly update our review queue.
Thanks!
Hi,
I’m not a developer of the code. There are certain short-comings into strict restrictions that seems to make utilities like ncdu ill suited for anything except classic confinement.
I do apologise but it seems that we’re misunderstanding each other. There is nothing on my side I can do to make this work any differently under strict confinement as I do not control the code. As mentioned previously by @alexmurray that we could review the current categories with someone like @pedronis.
you mean ncdu is not opensource so you could apply a patch during packaging ?
Hi @ogra
I can only package the code as it is. We tried different things as mentioned in this and previous threads that did not help to make it work well with strict confinement. If a system has only one volume there seems to be no issues. Problems creep in on hosts with multiple drives that is not USB/external. Usually this is not an issue on Desktop installs but servers often have more than one drive and ncdu is a tool used on servers to find datahogs.
Here is the problem. on my host with these 2 drives:
sda 31.5G disk
nvme0n1 238.5G disk
when I run ncdu on any location on nvme0n1 or on a External USB works fine. When I run it on sda volume I get an error that is not listed in snappy debug
Error: could not open /var/lib/snapd/void
Error reading directory: Permission denied
Like a terminal emulator, a tool like ncdu or gdu needs to read and delete across the whole system. The gdu developer has implemented a work around when gdu executes from a snap but even then it can run into problems.
I guess I could be less pedantic and push ncdu onward as is but I feel there is a conversions to be had that we are not getting to.