Description of problem:

using a script that run this : 

    export loop=$(losetup -f) && \
    losetup $loop $1 && \
    modprobe block2mtd block2mtd=$loop,131072 && \
    sleep 2 && \
    modprobe jffs2 && \
    sleep 2 && \
    modprobe mtdblock && \
    sleep 2 && \
    mount -t jffs2 -o ro /dev/mtdblock0 $2 && \

to mount jffs2 file as a loopback device, i see this error in the logs :


SELinux is preventing hald (hald_t) "getattr" access to device /dev/mtdblock0.

Description détaillée:

SELinux has denied the hald (hald_t) "getattr" access to device /dev/mtdblock0.
/dev/mtdblock0 is mislabeled, this device has the default label of the /dev
directory, which should not happen. All Character and/or Block Devices should
have a label. You can attempt to change the label of the file using restorecon
-v '/dev/mtdblock0'. If this device remains labeled device_t, then this is a bug
in SELinux policy. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy
package. If you look at the other similar devices labels, ls -lZ /dev/SIMILAR,
and find a type that would work for /dev/mtdblock0, you can use chcon -t
SIMILAR_TYPE '/dev/mtdblock0', If this fixes the problem, you can make this
permanent by executing semanage fcontext -a -t SIMILAR_TYPE '/dev/mtdblock0' If
the restorecon changes the context, this indicates that the application that
created the device, created it without using SELinux APIs. If you can figure out
which application created the device, please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this application.

Autoriser l'accès:

Attempt restorecon -v '/dev/mtdblock0' or chcon -t SIMILAR_TYPE '/dev/mtdblock0'

Informations complémentaires:

Contexte source               system_u:system_r:hald_t:s0
Contexte cible                system_u:object_r:device_t:s0
Objets du contexte            /dev/mtdblock0 [ blk_file ]
source                        hald
Chemin de la source           2F7573722F7362696E2F68616C64202864656C6574656429
Port                          <Inconnu>
Hôte                         akroma.ephaone.org
Paquetages RPM source         
Paquetages RPM cible          
Politique RPM                 selinux-policy-3.6.12-72.fc11
Selinux activé               True
Type de politique             targeted
MLS activé                   True
Mode strict                   Enforcing
Nom du plugin                 device
Nom de l'hôte                akroma.ephaone.org
Plateforme                    Linux akroma.ephaone.org
                              2.6.29.6-213.fc11.i686.PAE #1 SMP Tue Jul 7
                              20:59:29 EDT 2009 i686 i686
Compteur d'alertes            11
Première alerte              sam. 22 août 2009 17:59:35 CEST
Dernière alerte              sam. 22 août 2009 19:53:16 CEST
ID local                      2c12a637-b625-401f-8c15-28f5334356c0
Numéros des lignes           

Messages d'audit bruts        

node=akroma.ephaone.org type=AVC msg=audit(1250963596.144:29391): avc:  denied  { getattr } for  pid=1572 comm="hald" path="/dev/mtdblock0" dev=tmpfs ino=1044226 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=blk_file

node=akroma.ephaone.org type=SYSCALL msg=audit(1250963596.144:29391): arch=40000003 syscall=195 success=no exit=-13 a0=bfe88b2c a1=bfe88aac a2=366ff4 a3=bfe88aac items=0 ppid=1 pid=1572 auid=4294967295 uid=68 gid=68 euid=68 suid=68 fsuid=68 egid=68 sgid=68 fsgid=68 tty=(none) ses=4294967295 comm="hald" exe=2F7573722F7362696E2F68616C64202864656C6574656429 subj=system_u:system_r:hald_t:s0 key=(null)


As I assume that the device is created using the kernel, i guess that's a kernel bug ?