syscall_4294967295

[Pas]

Hello!

Thanks for the quick response and for the hint! After testing with
-fveseccomp,prctl
it turns out that:

docker-engine 1.10.1-0~wily uses seccomp (prctl PR_SET_SECCOMP,
SECCOMP_MODE_FILTER and PR_CAPBSET_DROP ...), whereas 1.10.1-0~jessie
doesn't. Though eventually by default Docker will filter out (almost all?)
syscalls:
https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities


Cheers,
Pas

On Sat, Feb 13, 2016 at 5:24 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:

> Hi,
>
> On Sat, Feb 13, 2016 at 04:05:50AM +0100, Pas wrote:
> > Hello!
> >
> > I would like to ask for a bit of help and maybe report a bug (but it's
> > probably just a known, however, a rather confusing behavior of strace).
> >
> > While running serf (a Raft consensus agent) in Docker (which uses cgroups
> > and kernel namespaces) I got a strange error. ("==> Failed to start the
> > Serf agent: Error creating Serf: Failed to create memberlist: Failed to
> > start TCP listener. Err: listen tcp 0.0.0.0:7946: socket: operation not
> > permitted") But the process inside the container should be behaving as a
> > process running as root, with all the necessary capabilities.
> >
> > So, strace-ing from the host (cannot strace/ptrace from the container
> > without using --privileged), I get the following trace:
> >
> > ...
> > [pid 17148] read(3,  <unfinished ...>
> > [pid 17144] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
> > [pid 17148] <... read resumed> "", 4096) = 0
> > [pid 17144] <... clock_gettime resumed> {939382190280542405,
> > 579195224836800512}) = 0
> > [pid 17148] close(3 <unfinished ...>
> > [pid 17144] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
> > [pid 17148] <... close resumed> )       = 0
> > [pid 17144] <... clock_gettime resumed> {4155469542819979293,
> 17314723865})
> > = 0
> > [pid 17148] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
> > [pid 17144] _newselect(0, NULL, NULL, NULL, {85899345920, 86034069969}
> > <unfinished ...>
> > [pid 17148] <... clock_gettime resumed> {4155579120320602141,
> > 598189438530486336}) = 0
> > [pid 17148] futex(0x18928620, FUTEX_WAKE, 1) = 1
> > [pid 17146] <... futex resumed> )       = 0
> > [pid 17146] _newselect(0, NULL, NULL, NULL, {429496729600, 429631460482}
> > <unfinished ...>
> > [pid 17144] <... _newselect resumed> )  = 0 (Timeout)
> > [pid 17144] clock_gettime(CLOCK_MONOTONIC, {940046419857770693,
> > 579195224836800512}) = 0
> > [pid 17144] clock_gettime(CLOCK_REALTIME,  <unfinished ...>
> > [pid 17148] syscall_4294967295(0x1, 0x18935730, 0, 0, 0, 0xff <unfinished
> > ...>
> > [pid 17144] <... clock_gettime resumed> {4156106598139125789,
> 17314723865})
> > = 0
> > [pid 17148] <... syscall_4294967295 resumed> ) = -1 (errno 1)
>
> 4294967295 is (unsigned int) -1.
> Looks like a side effect from a seccomp filter that messes up with
> syscalls.  Try strace -fveseccomp,prctl to check this hypothesis.
>
>
> --
> ldv
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160215/47798366/attachment.html>