Q: Is there a way to handle SIGSYS/ActTrap in go code? about libseccomp-golang

[pcmoore]

Hi @yvesf, I don't have an answer for you right now, but @drakenclimber and myself will be spending a bit more time with the libseccomp golang bindings in the near future; hopefully we will be able to answer your question better at that point in time.

If you do find a better answer, please let us know!

[drakenclimber]

I looked into this issue a little bit this morning.

I created a small demo where I also can override siginfo.si_code to 0.

I agree, the info->si_code = 0; line really stinks, but that seems like a golang issue and not a seccomp or seccomp-golang issue.

In that case Go dispatches the signal but the unfortunate side-effect is that the caller of the syscall is then no longer blocked and returns. I don't know how to prevent that and still it's an ugly hack.

For me anyway, the actual signal handler itself behaved just as it would in C. I didn't experience the nonblocking behavior you outlined above.

With this handler, here's what I saw:

static void mySigHandler(int signum, siginfo_t *info, void *context) {
        fprintf(stderr, "received of SIGSYS. si_syscall=%d\n", info->si_syscall);
        fflush(stderr);

        info->si_code = 0;
        sleep(10);
        exit(5);
}

$ ./traptest 
received of SIGSYS. si_syscall=260
<as requested, there was a 10-second delay before the console returned>

In the following case, I commented out the exit(). Just like in C, the signal was handled - poorly I might add :) - and the main program continued to run after the handler completed. I didn't see any strange nonblocking behavior here.

static void mySigHandler(int signum, siginfo_t *info, void *context) {
        fprintf(stderr, "received of SIGSYS. si_syscall=%d\n", info->si_syscall);
        fflush(stderr);

        info->si_code = 0;
        sleep(10);
        //exit(5);
}

$ ./traptest 
received of SIGSYS. si_syscall=260
<there was a 10-second delay before the following line printed>
should never reach me

[kolyshkin]

@drakenclimber @yvesf so, should this be closed as we're unable to reproduce it?

[drakenclimber]

@drakenclimber @yvesf so, should this be closed as we're unable to reproduce it?

Yes, I believe so. @yvesf, feel free to reopen this issue if new information is available. Thanks, all.