On 8/9/07, cornel panceac <cpanceac@xxxxxxxxx> wrote:
# 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@xxxxxxxxx>:On 8/8/07, dragoran < drago01@xxxxxxxxx> 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@comatose ~]# dmesg -c < /dev/null
> [root@comatose ~]# dmesg
> [root@comatose ~]# /etc/init.d/haldaemon start
> Starting HAL daemon: [FAILED]
> [root@comatose ~]# dmesg
> [root@comatose ~]#
>
> [root@comatose log]# /usr/sbin/hald
> [root@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@xxxxxxxxxx
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@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
If I remember correctly, that is the same error I was getting, a relabel shouldn't take to long.
# touch /.autorelabel
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
