Stracing a configure hook

snapd
1

Hi all!
I’ve a go-lang app, that running in configure hook, and it is failing if we add “network-control” plug in plugs section of configure hook (it begin to fails with error “exec.Command() failed! Error: %d open /dev/null: operation not permitted” - and this theoretically should not be related to “network-control” plug as I can understand).
So, I trying to understand, why it failing, and I want to use strace for this. To do this, I’ve added strace binary in my snap, and in configure hook, I have this:

${SNAP}/bin/strace ${SNAP}/bin/failing_binary

But, it’s not works - strace in strict mode failing with error “PTRACE_TRACEME: Operation not permitted”. In dev mode it works, but - in dev mode our binary isn’t failing.
I’ve googled a lot, and only found instructions about snap run --strace … - but, looks like in this case binary will be in different context (it isn’t failing even if snap was installed in strict mode).

So, question is - is there a way to strace things inside configure hook in strict mode?

Thanks a lot!

2

The snapd team has seen the question, and we’re thinking about it. It’s a good one.

2 Likes
3

Thanks, Chipaca!

For now, I’ve used “quick-and-dirty” solution - added 30 second delay (sleep) in debuggable binary, do “snap set …” , and connect strace from other terminal to PID of debuggable binary.

While investingating this, I’ve found one interesting thing. If “network-control” plug is connected, /dev/null became non-accessible from snap. Is this expected?

I’ve created “dumb” snap with configure hook like this:

#!/usr/bin/env bash set -x exec >> ${SNAP_COMMON}/configure-hook.log 2>&1 echo “$(date ‘+%Y-%m-%d %H:%M:%S’) configure-hook: Entering hook” ls -la /dev/null cat /dev/null

It installs without problem, and in logs (after install) I see normal prints:

  • echo ‘2019-01-14 15:26:36 configure-hook: Entering hook’ 2019-01-14 15:26:36 configure-hook: Entering hook
  • ls -la /dev/null crw-rw-rw- 1 root root 1, 3 Jan 14 14:44 /dev/null
  • cat /dev/null ++ date ‘+%Y-%m-%d %H:%M:%S’

But, if I do " sudo snap connect testsnap:network-control :network-control" and then do “snap set testsnap testparam=1” - I’ll get this:

  • echo ‘2019-01-14 15:28:25 configure-hook: Entering hook’ 2019-01-14 15:28:25 configure-hook: Entering hook
  • ls -la /dev/null crw-rw-rw- 1 root root 1, 3 Jan 14 15:28 /dev/null
  • cat /dev/null cat: /dev/null: Operation not permitted

Is this normal, and we should avoid access to /dev/null if we need network-control plug? Or maybe this is a bug?

Thanks in advance! Have a nice day :slight_smile:

1 Like
4

You may want to check out the source:

5

I suspect this has something to do with the device control group that is enforced when network-control is connected. Currently a snap is only put into a device cgroup if it plugs any interfaces that use the udev backend, and network-control is one of those. I would think access to /dev/null should always be allowed, perhaps a default udev tagging rule for /dev/null needs to always be added whenever the device cgroup is enabled?

@jdstrand probably can speak better to this

2 Likes
6

I can reproduce this /dev/null access denied issue with the following spread test https://github.com/snapcore/snapd/compare/master...mvo5:network-control-in-confiure-hook-test?expand=1

2 Likes
7

/dev/null is supposed to be added to the device cgroup unconditionally: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/udev-support.c#L169

You can check to see if it is in the device cgroup by looking for c 1:3 rwm in /sys/fs/cgroup/devices/snap.name.cmd/devices.list.

If it isn’t there, we’d need to see why snap-confine isn’t adding the device. (cc @mvo5)

1 Like
8

I looked at this some more and it turns out there is a bug in the code that takes the udev tag and translates it to the cgroup name. One fix is in https://github.com/snapcore/snapd/pull/6378 - it will fix this use-case. We need to look at this harder though because with instances the mapping of tagname to cgroup name is ambiguous so we most likely need to update the way we build the tagname.

1 Like