Libseccomp: RFE : étendre la prise en charge de SCMP_FLTATR_API_SYSRAWRC à l'API de notification

Salut @alban.

Regardez SCMP_FLTATR_API_SYSRAWRC dans la page de manuel seccomp_attr_set(3) :

Un indicateur pour spécifier si libseccomp doit renvoyer les codes d'erreur système à l'appelant au lieu de la valeur par défaut -ECANCELED. Désactivé par défaut (valeur == 0).

Nous forçons -ECANCELED dans ce cas pour garantir une promesse de code de retour stable dans l'API libseccomp sur différentes versions du noyau/libc. Nous proposons le SCMP_FLTATR_API_SYSRAWRC pour les appelants qui souhaitent toujours voir le code de retour réel du noyau/libc, sachez simplement que nous ne garantissons pas un code de retour stable si vous activez cet attribut.

Je vais fermer ce problème en tant que NOTABUG, mais n'hésitez pas à continuer à en discuter ici si vous avez des questions supplémentaires. Nous pouvons rouvrir s'il semble qu'il y a un vrai problème qui doit être résolu.

Salut @pcmoore , merci pour la réponse rapide.

Nous proposons le SCMP_FLTATR_API_SYSRAWRC pour les appelants qui souhaitent toujours voir le code de retour réel du noyau/libc

Mais les nouvelles fonctions

• seccomp_notify_receive
• seccomp_notify_respond
• seccomp_notify_id_valid

utilisent _rc_filter() et non _rc_filter_sys() , donc SCMP_FLTATR_API_SYSRAWRC ne devrait pas avoir d'effet, si je ne me trompe pas.

Mais les nouvelles fonctions ... utilisent _rc_filter() et non _rc_filter_sys() ...

Ah... désolé. En fait, cela va plus loin que le niveau de l'API, regardez dans "system.c" et vous verrez que les appels au niveau du système libseccomp ne les propagent pas jusqu'aux fonctions au niveau de l'API. En regardant les pages de manuel, il semble que nous ne fassions aucune réclamation à propos SCMP_FLTATR_API_SYSRAWRC pour l'API de notification (voir seccomp_load(3) pour un contre-exemple).

Je vais continuer et rouvrir cela en tant que RFE puisque nous ne faisons actuellement aucune déclaration à propos de ce fonctionnement.

@drakenclimber Je pense qu'il s'agit de matériel v2.6.x (éventuellement v2.5.2) car je ne veux pas ralentir la version v2.5.1. Si vous pensez autrement faites le moi savoir.

Merci!

Pour mémoire, j'ai trouvé la solution de contournement du côté Golang pour pouvoir distinguer ENOENT et EINTR, avec ce modèle de code :

-   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
    }

Avec cela, cela semble bien fonctionner avec libseccomp-2.5.0,