Can't run the simplest ping script

Hey Team,

I’ve got the following snapcraft.yaml:

name: hy-pinger
summary: A utility to test networking within a snap
description: |
  Sends pings, hopefully :)

version: '1.0'
confinement: strict
grade: devel
base: core20
  - build-on: ['all']
    run-on: ['armhf']

# ========================================================================

    command: bin/ping-google
       - network
       - network-bind

    plugin: dump
    source: ./sources/
      ping-google: bin/ping-google

with a simple bash script “ping-google”:



I’m building it for Raspberry Pi Compute module 3. Builds fine. On the Pi it installs fine, plugs connect fine but when I run hy-pinger from command line I get:

ping: socket: Operation not permitted

Why would that be ?

Can you check the output of dmesg to see if there are any denials getting logged?

also, install the snappy-debug snap and run it in a second terminal …

that should give useful suggestions what additional interfaces you need (IIRC ping is low level enouhg to require network-control)

Yeah, ping is typically setuid so requires ‘capability setuid’ in the apparmor profile. Both are allowed by network-observe (or network-control). See Executing ping within a snap

Appreciate all the responses so far! I’ve added both network-control and network-observe to the snapcraft.yaml file, rebuilt the snap and installed it, manually connected both - all went fine, but that didn’t help :frowning: Still getting operation not permitted issue

I also ran snappy-debug in a background terminal but it doesn’t log anything when I run the command hy-pinger

I had a look at dmesg but no errors there, I can ping normally on the system by hand.

can you ping if you call the app with sudo ?

1 Like

@ogra yes I can , but I’ve never seen anywhere the need to use sudo to run a ping :sweat_smile: so I’d prefer not to just leave it like that :sweat_smile:

You need to use sudo because normally the ping executable is setuid to root but your snap build will have stripped this permission because of the way snaps are meant to operate. Setuid executables aren’t generally allowed in a snap package.

By running with sudo you are recreating the effect of setuid.

@daniel Thank you for your help and the explanation, much appreciated!

However I’m not so sure on this anymore: if we have to use sudo to run something within a snap does that mean we’re still confined only to snap’s environment ? Are we still “safe” ? :sweat_smile:

yes, you are safe, snap applications run on top of the base snap you defined in your snapcraft.yaml (core20 in the above case) , this is a readonly squashfs so it can not be modified. along with this the confinement monitors all binary execution via seccomp, restricts all file system access through apparmor, and uses namespaces and cgroups to control all aspects of the application.

all you can see is the readonly core20 environment which even root can not do much in.

additionally all you can see from the outside world of this environment is mediated through interfaces that give you very fine grained access to the minimal set of host resources needed for the specific access.

BTW: you can inspect this environment by spawning a shell inside your snap like:

    sudo snap run --shell hy-pinger

(leave it with “exit” or ctrl-c)

1 Like

That sounds good, I appreciate the explanation @ogra , I’m not so good on understanding things like seccomp and apparmor in details and the reason I asked if we’re safe with sudo was because I thought what if the simple little ping script is fetched by the host system directly from /snap/bin and ran on host system directly, bypassing all that the snap has to offer because afterall the hy-pinger script has a hashbang pointing to the system’s root, it does not have something like #!{SNAPS_ENV}/bin/bash you know what I mean ?

I’ll double check that, probably will need to use something like strace to confirm all the execution is directed through the snap environment.

Once again though thank you for taking time to help me out with this!

nope … it has not … it has a hashbang pointing to your base snap which it uses as / … so /bin/bash is effectively (from a host POV) /snap/core20/current/bin/bash … your snap sees
/snap/core20/current/ as / …

Apologies, my mistake I meant the ping-google bash script.

I confirmed today with the use of strace that hy-pinger is executed through the snap environment. So all is good. I know that this is what you expected but I wanted to check for myself that everything compiled correctly and executes correctly, I didn’t mean to doubt what you said.

I’ll mark the correct answer for this post and will try to write one or two more involved snaps. Appreciate everyone’s help here and the great work you guys are doing!

1 Like

hmmm, no something is wrong, I have commented out all the plugs, recompiled, reinstalled but I still can run hy-pinger with sudo. So now I have a strictly confined snap that can run correctly with sudo no matter if I declare plugs or not. I don’t understand why ? :frowning:

I checked the snap connections but there’s nothing left over

what does this report?

snap debug confinement


snap debug sandbox-features

You’re likely running on a kernel that doesn’t include the required bits for strict confinement to operate correctly so your snaps are able to escape the sandbox.

along with what @daniel said, the full output of snap version would be interesting as well …