Libseccomp: RFE: 알림 API로 SCMP_FLTATR_API_SYSRAWRC 지원 확장

안녕하세요 @alban입니다.

seccomp_attr_set(3) 맨페이지에서 SCMP_FLTATR_API_SYSRAWRC 를 보십시오.

libseccomp가 기본 -ECANCELED 대신 시스템 오류 코드를 호출자에게 다시 전달해야 하는지 여부를 지정하는 플래그입니다. 기본값은 꺼짐(값 == 0)입니다.

다른 커널/libc 버전에서 libseccomp API의 안정적인 반환 코드 약속을 보장하기 위해 이 경우 -ECANCELED 를 강제 실행합니다. 우리는 여전히 실제 커널/libc 반환 코드를 보고자 하는 호출자를 위해 SCMP_FLTATR_API_SYSRAWRC 를 제공합니다. 다만 해당 속성을 활성화하면 안정적인 반환 코드를 보장하지 않는다는 점에 유의하십시오.

이 문제를 NOTABUG로 마무리하겠습니다. 하지만 추가 질문이 있는 경우 여기에서 계속 논의해 주시기 바랍니다. 해결해야 할 실제 문제가 있는 것처럼 보이면 다시 열 수 있습니다.

안녕하세요 @pcmoore 빠른 답변 감사합니다.

실제 커널/libc 반환 코드를 보고자 하는 호출자를 위해 SCMP_FLTATR_API_SYSRAWRC를 제공합니다.

그러나 새로운 기능

• seccomp_notify_receive
• seccomp_notify_respond
• seccomp_notify_id_valid

_rc_filter() 가 아닌 _rc_filter_sys() 를 사용하고 있으므로 내가 틀리지 않는다면 SCMP_FLTATR_API_SYSRAWRC 는 효과가 없어야 합니다.

그러나 새로운 기능은 ... _rc_filter_sys()가 아닌 _rc_filter()를 사용하고 있습니다 ...

아 ... 죄송합니다. 사실, 그것은 API 레벨보다 더 깊습니다. "system.c"를 보면 libseccomp 시스템 레벨 호출이 API 레벨 함수까지 전파하지 않는다는 것을 알 수 있습니다. 맨페이지를 보면 알림 API에 대해 SCMP_FLTATR_API_SYSRAWRC 에 대해 어떠한 주장도 하지 않는 것으로 보입니다(반대 예는 seccomp_load(3) 참조).

우리는 현재 이 작업에 대해 어떠한 주장도 하지 않기 때문에 이것을 RFE로 다시 열겠습니다.

@drakenclimber v2.5.1 릴리스를 늦추고 싶지 않기 때문에 이것이 v2.6.x(v2.5.2일 수도 있음) 자료라고 생각합니다. 다른 생각이 들면 저에게 알려주십시오.

감사 해요!

기록을 위해 다음 코드 패턴을 사용하여 ENOENT와 EINTR를 구별할 수 있도록 Golang 측에서 해결 방법을 찾았습니다.

-   if retCode := C.seccomp_notify_respond(C.int(fd), resp); retCode != 0 {
-       return errRc(retCode)
+   for {
+       retCode, errno := C.seccomp_notify_respond(C.int(fd), resp)
+       if errno == syscall.EINTR {
+           continue
+       }
+       if errno == syscall.ENOENT {
+           return errno
+       }
+       if retCode != 0 {
+           return errRc(retCode)
+       }
+       break
    }

이를 통해 libseccomp-2.5.0에서 잘 작동하는 것 같습니다.