Karl Larsen wrote:
Erich Zigler wrote:
On Sat, 13 Oct 2007 11:32:11 -0600 Karl Larsen <k5di@xxxxxxxxxx> wrote:
I will not turn on SELinux again until I see a update for dbus.
It appears dbus is used only by SELinux.
Incorrect. dbus is not used by SELinux. dbus and SELinux do not
depend or require each other. Many GNOME/GTK applications you are
running on your machine require dbus. If you do a ps auxww | grep dbus
right now you will see that it is running.
D-Bus is a message bus system, a simple way for applications to talk
to one another. In addition to interprocess communication, D-Bus helps
coordinate process lifecycle; it makes it simple and reliable to code a
"single instance" application or daemon, and to launch applications and
daemons on demand when their services are needed.
D-Bus supplies both a system daemon (for events such as "new hardware
device added" or "printer queue changed") and a per-user-login-session
daemon (for general IPC needs among user applications). Also, the
message bus is built on top of a general one-to-one message passing
framework, which can be used by any two apps to communicate directly
(without going through the message bus daemon). Currently the
communicating applications are on one computer, or through unencrypted
TCP/IP suitable for use behind a firewall with shared NFS home
directories. (Help wanted with better remote transports - the transport
mechanism is well-abstracted and extensible.)
Source: http://www.freedesktop.org/wiki/Software/dbus
For an incomplete list of applications that require dbus:
http://www.freedesktop.org/wiki/Software/DbusProjects
Please please please do some research and googling before you try to
pass off halfcocked misinformation to the list. This negatively impacts
you, this list, and the community. It also affects the potential
user/sysadmin googling for this same issue which comes upon your
misinformation and decides to act on it.
- Erich
I DID Google dbus and it came up with many but one was interesting
to me because it was another user having trouble with SELinux and he
found the same problem I have. He said the problem in dbus was fixed
in FC6 but is again a problem in F7.
Now. Due to the problem with dbus I can't use SELinux because it
uses dbus and has a problem with that. So your wrong with thinking
SELinux does not use dbus, It certainly does and that I can prove.
Here is what they said on the selinux list:
The messages log is filling up with stuff like this:
dbus: Can't send to audit system: USER_AVC avc: received policyload
notice (seqno=2) : exe="/bin/dbus-daemon" (sauid=539, hostname=?,
addr=?, terminal=?)
nscd: Can't send to audit system: USER_AVC avc: received policyload
notice (seqno=2) : exe="?" (sauid=28, hostname=?, addr=?, terminal=?)
dbus and nscd are the nosiest culprits.
Googling for what look like the key phrases gets me tons of hits from
2005, but nothing recent and nothing pertaining to FC7 (but having
never used an FC release before, I could be wrong).
Could somebody please tell me how to turn this noise off?
These are not SELinux errors so to speak, they are auditing errors. When
you update policy probably during a yum update, any application that is
running as a SELinux policy enforcer, gets a message from the kernel
telling that the policy has been updated. These apps then attempt to
send a message to the audit system stating that they have reloaded the
policy. These errors are generated because the applications are running
as a normal user and are not allowed to send to the audit.log. So the
audit subsystem sends a message to /var/log/messages. So other then
filling you /var/log/messages file, these errors can be ignored. The
dbus error has been fixed in FC6 and seems to have resurfaced. I have
not seen the nscd error. Both should be reported as bugzillas to nscd,
and dbus.
--
fedora-selinux-list mailing list
fedora-selinux-list redhat com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
So this is what I am acting on. And to act you wait for things to be
fixed.
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.