Red Hat Bugzilla – Bug 452830
Thunar fails to start in a vnc session
Last modified: 2008-06-30 16:14:33 EDT
Description of problem: Thunar won't launch from inside a vnc session. My ~/.vnc/xstartup contains: #!/bin/sh # Uncomment the following two lines for normal desktop: # unset SESSION_MANAGER # exec /etc/X11/xinit/xinitrc [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources xsetroot -solid grey vncconfig -iconic & xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then eval `dbus-launch --sh-syntax --exit-with-session` fi exec xfce4-session On starting the vncserver service, an xfce4 session is started, as expected, but thunar fails to start, so the desktop is not managed etc. Trying to start thunar manually fails with the following messages: $ thunar process 6102: arguments to dbus_connection_send_with_reply_and_block() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-connection.c line 3289. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted Version-Release number of selected component (if applicable): $ rpm -qa | grep xfce xfce4-mailwatch-plugin-1.0.1-8.fc9.x86_64 libxfcegui4-4.4.2-2.fc9.x86_64 xfce4-appfinder-4.4.2-2.fc9.x86_64 libxfce4util-4.4.2-2.fc9.x86_64 xfce4-session-4.4.2-3.fc9.x86_64 imsettings-xfce-0.99.6-5.fc9.x86_64 xfce-mcs-manager-4.4.2-2.fc9.x86_64 xfce-utils-4.4.2-4.fc9.x86_64 xfce4-mixer-4.4.2-2.fc9.x86_64 libxfce4mcs-4.4.2-2.fc9.x86_64 xfce4-session-engines-4.4.2-3.fc9.x86_64 xfce4-icon-theme-4.4.2-1.fc9.noarch xfce4-panel-4.4.2-4.fc9.x86_64 xfce-mcs-plugins-4.4.2-4.fc9.x86_64 $ rpm -qa | grep thunar thunar-volman-0.2.0-2.fc9.x86_64 $ rpm -qa | grep vnc vnc-libs-4.1.2-30.fc9.x86_64 vnc-4.1.2-30.fc9.x86_64 gtk-vnc-0.3.6-1.fc9.x86_64 gtk-vnc-python-0.3.6-1.fc9.x86_64 vnc-server-4.1.2-30.fc9.x86_64 How reproducible: Everytime Steps to Reproduce: See above.
Just in case it matters: $ rpm -qa | grep xfwm xfwm4-theme-nodoka-0.1-1.fc9.noarch xfwm4-4.4.2-3.fc9.x86_64
And, also: ]$ rpm -qa | grep dbus dbus-python-0.82.4-2.fc9.x86_64 dbus-1.2.1-2.fc9.x86_64 dbus-libs-1.2.1-2.fc9.x86_64 dbus-x11-1.2.1-2.fc9.x86_64 dbus-glib-0.74-8.fc9.x86_64
This looks like it might be a selinux policy issue. Do you have selinux set to enforcing mode? (check /etc/sysconfig/selinux and/or getenforce) If so, can you see if you see any avc denial messages in /var/log/audit/audit.log. Also, see if 'setenforce 0' causes it to work. I see the following avc here: type=USER_AVC msg=audit(1214595857.856:724): user pid=2367 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.40 spid=2418 tpid=16743 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'
Yes indeed, switching SElinux to permissive allows thunar to start, and everything is as expected. I do see exactly the same avc in audit.log as you.
ok. I am adding dwalsh to CC here. Dan: Is there anything that needs to change in policy or something I need to change in Thunar to get this working?
You can allow this for now. # audit2allow -M mypol -l -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.3.1-72.fc9.noarch