Starting HAL daemon: [FAILED]

[cornel panceac]

# sealert -l 7b733fe2-9be2-40f7-bccc-6516e261b46c
Summary
    SELinux is preventing /usr/sbin/hald (hald_t) "read" to reload
(var_lib_t).

Detailed Description
    SELinux denied access requested by /usr/sbin/hald. It is not expected
that
    this access is required by /usr/sbin/hald and this access may signal an
    intrusion attempt. It is also possible that the specific version or
    configuration of the application is causing it to require additional
access.

Allowing Access
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for reload, restorecon -v reload
If
    this does not work, there is currently no automatic way to allow this
    access. Instead,  you can generate a local policy module to allow this
    access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or
you
    can disable SELinux protection altogether. Disabling SELinux protection
is
    not recommended. Please file a
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.

Additional Information

Source Context                system_u:system_r:hald_t
Target Context                system_u:object_r:var_lib_t
Target Objects                reload [ file ]
Affected RPM Packages         hal-0.5.10-0.git20070731.fc8 [application]
Policy RPM                    selinux-policy-3.0.5-2.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall_file
Host Name                     home-1367252.galati.astral.ro
Platform                      Linux home-1367252.galati.astral.ro
                              2.6.23-0.74.rc2.git1.fc8 #1 SMP Tue Aug 7
19:21:07
                              EDT 2007 i686 athlon
Alert Count                   5
First Seen                    Wed Aug  8 15:42:26 2007
Last Seen                     Thu Aug  9 07:28:11 2007
Local ID                      7b733fe2-9be2-40f7-bccc-6516e261b46c
Line Numbers

Raw Audit Messages

avc: denied { read } for comm="hald" dev=sda1 egid=0 euid=0
exe="/usr/sbin/hald"
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="reload" pid=3080
scontext=system_u:system_r:hald_t:s0 sgid=0 subj=system_u:system_r:hald_t:s0
suid=0 tclass=file tcontext=system_u:object_r:var_lib_t:s0 tty=(none) uid=0



since it's a freshly installed system, i'm not tempted to relabel. any other
fix?

2007/8/8, Justin Conover <justin.conover at gmail.com>:
>
>
>
> On 8/8/07, dragoran <drago01 at gmail.com> wrote:
> >
> > Justin Conover wrote:
> > > HAL will not start, is there any thing I can look at for logs or why.
> > > The system is updated to current rawhide.
> > >
> > > [root at comatose ~]# dmesg -c < /dev/null
> > > [root at comatose ~]# dmesg
> > > [root at comatose ~]# /etc/init.d/haldaemon start
> > > Starting HAL daemon:                                       [FAILED]
> > > [root at comatose ~]# dmesg
> > > [root at comatose ~]#
> > >
> > > [root at comatose log]# /usr/sbin/hald
> > > [root at comatose log]# /etc/init.d/haldaemon status
> > > hald (pid 3027) is running...
> > >
> > maybe a selinux issue?
> > any avc messages?
> >
> > --
> > fedora-test-list mailing list
> > fedora-test-list at redhat.com
> > To unsubscribe:
> > https://www.redhat.com/mailman/listinfo/fedora-test-list
>
>
>
> Relabeling does allow hald to start during the boot process, however now.
> nm-applet seg faults...
>
>
>
> --
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-test-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20070809/a271f3fb/attachment.htm>