This one is slightly more interesting.
You need 1.8 (or patched <1.8 as per the previous thread) for this one
to make sense; without it you're just going to get drowned in warning
messages and not see the real issue.
This one is the real issue :-)
In go, when calling syscall.Exec to a setuid root binary, sometimes
(about 4% of the times, on my machine, but it's hardware- and
load-dependent), the exec'ed process will find itself running with
effective uid different to zero. That is, a setuid root binary will
find itself running as non-root. As the process that sets up
confinement is setuid root (in distros where setuid is favoured over
capabilities), this means the snap app falls on its face.
TODO: check if something similar happens when using caps
This is *probably* a bug in Go, but it only seems to arise when using
syscall.Exec, which as far as I can tell is unsupported (the whole
syscall package is unsupported -- not covered by the go1 compatibility
promise -- and its replacement, golang.org/x/sys/unix, is ominously
missing Exec).
Having said that, it might be a bug in the kernel ;-)
And I say this because if you pin the process to a single cpu, the
issue doesn't arise.
Anyway, code to repro this is at
https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813
on my machine,
$ for i in `seq -w 9999`; do ./a_c; done | wc -l
0
$ for i in `seq -w 9999`; do ./a_go; done | wc -l
394
And,
$ for i in `seq -w 9999`; do taskset 2 ./a_go; done | wc -l
0
Gnarly!
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
