syscall_4294967295

[Dmitry V. Levin]

On Mon, Feb 15, 2016 at 09:30:18AM -0500, Mike Frysinger wrote:
> On 15 Feb 2016 15:21, Dmitry V. Levin wrote:
> > On Mon, Feb 15, 2016 at 12:12:09PM +0100, Pas wrote:
> > > 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
> > 
> > On entering syscall, seccomp kernel hooks are executed before ptrace
> > kernel hooks.  As result, when some syscall is blocked by seccomp filter
> > using SECCOMP_RET_ERRNO statement, on many architectures including x86 and
> > x86_64 the syscall number is clobbered and strace sees -1 in its place.
> > 
> > You can play with strace/tests/seccomp.c and see it yourself.
> 
> would PTRACE_O_TRACESECCOMP help here ?

Only for SECCOMP_RET_TRACE actions.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160215/94e2e84e/attachment.bin>