Hello tout le monde.

En ce moment j'ai un problème avec xvidcore en provenance du dépôt RPMfusion-free. Plus précisément avec sa version 1.2.2-1.fc14

Dès que je lance une application qui va lire une vidéo mpeg-4, exemple Totem, j'ai SELinux qui le bloque et qui m'indique une allerte.

Le message de SELinux est: 
The source of process: /usr/bin/totem
Attempted this acces: execstack
On this process: Unknow
Pour quelle raison xvidcore veut-il executer le stack?
Avec-vous la même chose chez vous?
Bonjour,

je ne connais pas de composant nommé « divxcore » dans RPM Fusion. Le message que tu as posté n'est guère loquace, et surtout ne fait pas allusion à divxcore.
Qu'est-ce qui te laisse penser que divxcore serait responsable ? Que renvoie plutôt cette commande (en tant que root) ? 
grep totem /var/log/audit/audit.log
korbé wrote:Le message de SELinux est: 
The source of process: /usr/bin/totem
Attempted this acces: execstack
On this process: Unknow
Que retourne la commande:
sudo grep avc /var/log/audit/audit.log | grep -i NOM_DU_PROGRAMME
Pour créer une règle SElinux locale pour contourner le problème:
sudo grep avc /var/log/audit/audit.log | grep -i NOM_DU_PROGRAMME | audit2allow -M newpolicy
sudo semodule -i newpolicy.pp
Pikachu_2014 wrote:Bonjour,

je ne connais pas de composant nommé « divxcore » dans RPM Fusion. Le message que tu as posté n'est guère loquace, et surtout ne fait pas allusion à divxcore.
Qu'est-ce qui te laisse penser que divxcore serait responsable ? Que renvoie plutôt cette commande (en tant que root) ? 
grep totem /var/log/audit/audit.log
Bas c'est simple: Le problème ne vient que si je tente de lire une vidéo dans certains formats et si la version 1.2.2-1.fc14 de divxcore est installé. Si j'ai la version précédente, aucun problème.

Sinon dans audit.log: 
type=ANOM_ABEND msg=audit(1284368384.299:23): auid=500 uid=500 gid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3064 comm="totem" sig=6
type=ANOM_ABEND msg=audit(1292010642.726:25685): auid=500 uid=500 gid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=6982 comm="totem-video-thu" sig=11
type=SYSCALL msg=audit(1293555187.395:41): arch=40000003 syscall=125 success=no exit=-13 a0=bfc3c000 a1=1000 a2=1000007 a3=b62fce0c items=0 ppid=2091 pid=7869 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="avidemux0:sink" exe="/usr/bin/totem-video-thumbnailer" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=SYSCALL msg=audit(1293555188.234:42): arch=40000003 syscall=125 success=no exit=-13 a0=bf9b5000 a1=1000 a2=1000007 a3=addfdddc items=0 ppid=1 pid=7742 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="avidemux0:sink" exe="/usr/bin/totem" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=SYSCALL msg=audit(1293555309.456:43): arch=40000003 syscall=125 success=no exit=-13 a0=bf9b5000 a1=1000 a2=1000007 a3=a64fcddc items=0 ppid=1 pid=7699 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="avidemux1:sink" exe="/usr/bin/totem" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=SYSCALL msg=audit(1294257529.383:25858): arch=40000003 syscall=125 success=no exit=-13 a0=bfc9a000 a1=1000 a2=1000007 a3=accb7bec items=0 ppid=1 pid=15418 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="qtdemux0:sink" exe="/usr/bin/totem" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=SYSCALL msg=audit(1294257529.493:25859): arch=40000003 syscall=125 success=no exit=-13 a0=bfc9a000 a1=1000 a2=1000007 a3=accb7bec items=0 ppid=1 pid=15418 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="qtdemux0:sink" exe="/usr/bin/totem" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
xvidcore, pas divxcore. La différence est de taille puisqu'à une époque DivX distribuait une bibliothèque proprio. sous ce nom, même pour Linux.
Mmm, je pense pas que le problèmes vienne de SELinux. Sinon d'autres personne auraient le même.
Est-ce que le reste du monde a la même configuration logicielle que toi ?
Pikachu_2014 wrote:xvidcore, pas divxcore. La différence est de taille puisqu'à une époque DivX distribue une bibliothèque proprio. sous ce nom.
Mmm, je pense pas que le problèmes vienne de SELinux. Sinon d'autres personne auraient le même.
Est-ce que le reste du monde a la même configuration logicielle que toi ?
Bas j'imagine que beaucoup d'utilisateurs de Fedora ont installé gstreamer-FFmpeg, qui nécécite xvidcore.
J'ai xvidcore aussi sans aucun souci.

Simplement pour savoir si oui ou non SElinux est responsable d'un blocage, il suffit de l'arrêter le temps de faire une tentative et de voir ce qui se passe. C'est quand même la première des choses.
Sous $HOME, efface le répertoire caché gstreamer. Il peut y avoir un lien. Comme c'est du cache, il sera régénéré proprement à la prochaine reconnexion.

Dis nous si c'est ça ?
bonsoir à tous

j'ai eu le problème suivant
xvidcore était installé avec un fichier /usr/lib/libxvidcore.so.4 au lieu d'un lien symbolique
libxvidcore.so.4 --> libxvidcore.so.4.2

j'ai fait un yum remove xvidcore et install xvidcore qui a réglé le problème.

ce n'est peut-être pas la solution à votre problème mais vous pouvez toujours vérifier.
Le problème a été rapporté ici:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1560

Néanmoins il semble que la dernière mise à jour de xvidcore n'est pas été suffisamment testé. Il peut être interressant d'activer le dépot rpmfusion-free-updates-testing parfois pour vérifier les nouveau paquets et rapporter les problèmes au plus tot.
bonjour

j'ai oublié de préciser que je venais de faire une fresh install de fedora 14
suivie d'un yum update