Fzf snap mount-observe doesn't seem to have an effect

snap
1

I have an existing snap in the store for installing fzf, a command-line fuzzy finder.

Currently when executing the snap without any options, it defaults to executing a find command:

set -o pipefail; command find -L . -mindepth 1 ( -path ‘/.’ -o fstype ‘sysfs’ -o fstype ‘devfs’ -o fstype ‘devtmpfs’ -o fstype ‘proc’ ) -prune -o -type f -print -o -type L …

Complaining that it wasn’t able to execute that because of strict confinements and not having any plugs specified.

After discovering the snappy-debug snap, I decided to give it a try and indeed discovered some confinement issues:

$ snappy-debug INFO: Following ‘/var/log/syslog’. If have dropped messages, use: INFO: $ sudo journalctl --output=short --follow --all | sudo snappy-debug sysctl: permission denied on key ‘kernel.printk_ratelimit’ = AppArmor = Time: Nov 21 11:10:18 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/sys/kernel/mm/transparent_hugepage/hpage_pmd_size” pid=7733 comm=“fzf” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0 File: /sys/kernel/mm/transparent_hugepage/hpage_pmd_size (read) Suggestion:

  • adjust program to not access ‘/sys/kernel/mm/transparent_hugepage/hpage_pmd_size’

= AppArmor = Time: Nov 21 11:10:18 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/proc/7810/mountinfo” pid=7810 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000 File: /proc/7810/mountinfo (read) Suggestions:

  • adjust program to not access ‘@{PROC}/@{pid}/mountinfo’
  • add ‘mount-observe’ to ‘plugs’

= AppArmor = Time: Nov 21 11:10:18 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/proc/7810/mounts” pid=7810 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000 File: /proc/7810/mounts (read) Suggestions:

  • adjust program to not access ‘@{PROC}/@{pid}/mounts’
  • add one of ‘mount-observe, network-control’ to ‘plugs’

= AppArmor = Time: Nov 21 11:10:18 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/proc/7810/mountinfo” pid=7810 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000 File: /proc/7810/mountinfo (read) Suggestions:

  • adjust program to not access ‘@{PROC}/@{pid}/mountinfo’
  • add ‘mount-observe’ to ‘plugs’

= AppArmor = Time: Nov 21 11:10:18 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/proc/7810/mounts” pid=7810 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000 File: /proc/7810/mounts (read) Suggestions:

  • adjust program to not access ‘@{PROC}/@{pid}/mounts’
  • add one of ‘mount-observe, network-control’ to ‘plugs’

I added the following in my snapcraft.yml file and updated the snap, but apparently the output of snappy-debug is the same.

apps: fzf: command: fzf plugs: - mount-observe - home

I don’t know if this is a bug, or what else I could try for making this work.

$ snap --version snap 2.42.1 snapd 2.42.1 series 16 ubuntu 19.10 kernel 5.3.0-23-generic

2

did you connect the interface with snap connect <snapname>:<interface-name> ?

mount-observe surely does not auto-connect … (you can check the current state with snap connections <snapname>)

1 Like
3

Ah that indeed makes a difference!

± snap connect fzf-carroarmato0:mount-observe

This asks for my password and then fzf can do its thing.

Now the only complaint produced by snappy-debug is

$ snappy-debug INFO: Following ‘/var/log/syslog’. If have dropped messages, use: INFO: $ sudo journalctl --output=short --follow --all | sudo snappy-debug sysctl: permission denied on key ‘kernel.printk_ratelimit’ = AppArmor = Time: Nov 21 11:27:10 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/sys/kernel/mm/transparent_hugepage/hpage_pmd_size” pid=9133 comm=“fzf” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0 File: /sys/kernel/mm/transparent_hugepage/hpage_pmd_size (read) Suggestion:

  • adjust program to not access ‘/sys/kernel/mm/transparent_hugepage/hpage_pmd_size’

But this I’m not going to solve.

I’m wondering from a usability point of view how I would go about explaining this to a none technical user who just wishes to install the snap and expects everything to just work for him/her.

4

there are multiple ways here …

you can put it into the package description (and hope your users read it :stuck_out_tongue: )

you could write a wrapper script that checks if the interface is connected when the app is run and tells the user what to do

if your app qualifies you can ask for an auto-connection via the Request process

1 Like
5

FYI there is not currently an interface which allows access to transparent_hugepage, but there is a proposed interface (hugepages-observe) in snapd which would allow you to access this. Do you know why fzf needs to access hugepages?

1 Like
6

I’m not familiar with the code. I took a quick look and couldn’t find direct references to hupepages.

If you execute the command as is, it goes and enumerates everything it can find to allow you to fuzzy search through those results.

7

It’s probably okay to just ignore the denial for now then. How often does the denial happen?

8

It highly depends on the context.

If I execute fzf-carroarmato0.fzf in my home directory, it’s going to traverse everything in its path.

Since the snap folder resides by default in the home directory of the user, it will also attempt to read it and silently be halted by AppArmor from reading through certain directories:

= AppArmor = Time: nov 22 16:33:29 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/home/carroarmato0/snap/gnome-calculator/” pid=20636 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000

= AppArmor = Time: nov 22 16:33:29 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/home/carroarmato0/snap/phpstorm/” pid=20636 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000

= AppArmor = Time: nov 22 16:33:29 Log: apparmor=“DENIED” operation=“open” profile=“snap.fzf-carroarmato0.fzf” name=“/home/carroarmato0/snap/snapcraft/” pid=20636 comm=“find” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=1000 …

It’s just the nature of the beast.

With regards to /sys/kernel/mm/transparent_hugepage/hpage_pmd_size it looks like it will always try to read that everytime. So always :slight_smile:

9

Yes sorry if I was unclear but I was asking more about how often you see the transparent_hugepage access. If it happens a lot and is a nuisance, we could consider denying that access so that the denial doesn’t show up in the logs, but we would need to do so in a careful way so that interfaces like docker-support or the eventual hugepages-{observe,control} can provide this. We have a pattern for doing so, but it’s a bit of work so if it wasn’t a big issue then I would say just ignore it.

@jdstrand what do you think of making transparent-hugepage access default denied unless an interface is plugged that needs it, a la spec.SetUsesPtraceTrace() and friends?

10

Oh actually, the hugepage thing doesn’t appear in the prompt of the tool.
If it wasn’t for snappy-debug, I would have had no idea that it was even trying to read that.
It will spam the logs however.

I should ask the original author of the application if it’s a big deal or not, but since everything else seems to work I don’t think anything needs to be done.

11

Right that is more what I was getting at, the other denials and things are an orthogonal concern to this.

12

I actually added this to hardware-observe: https://github.com/snapcore/snapd/pull/7779/commits/0b93f63c1778acaa55dccc1418c4233798539fba

2 Likes