I've been having several problems recently with Nautilus and Gnome. This
started ever since I adjusted my Gnome settings to save session and
restore on login; I was simply too lazy to manually launch Firefox and
Evolution on login.
Consequently, on login, I potentially had multiple copies of Nautilus
starting up, depending on how I'd left the desktop at logout. ( That's
multiple windows, which Gnome collapses onto a single process, but I was
seeing multiple processes under the fault conditions ). Invariably, at
least one of them crashed.
This became unworkable recently when I found I could make entire
directories disappear from Nautilus, even though they really still
existed. I drilled to a given "dangerous" directory's parent
within /home, then attempted to drill one step further, only to find
that the child directory started to display, and then Nautilus
completely crashed. If I tried opening the directory in a new window,
the child window crashed, and the parent window removed the directory
from its top level listing. It seemed that the "vulnerable" directories
were those which had been recently modified.
Experimenting further, this seems to relate to "gam_server", as numerous
denial messages appear in SELinux logs referencing this process.
"gam_server" is part of gamin, as in:
$ rpm -qf --queryformat="%{name}: %{summary}\n" /usr/libexec/gam_server
gamin: Library providing the FAM File Alteration Monitor API
The SELinux avc's only related to gam_server running under the
"user_gnome_vfs_t" domain.
Based on what I've seen so far, my suspicion is that the
user_gnome_vfs_t domain needs read access to every directory which
user_t has access to, and that if user_t can get to a directory, but
user_gnome_vfs_t can't, the overall Nautilus system gets very very
confused for some reason.
For the present, I've added some extras to my local SELinux policy which
cover most directories which Nautilus is likely to want to see, and this
DOES appear to stop Nautilus crashing on login for the first time in
several months. I don't think this is the complete solution, though. I
suspect the proper solution is for Nautilus itself to gracefully recover
from a permission denial in either the user_t OR the user_gnome_vfs_t
components; or perhaps just simply abandon the user_gnome_vfs_t domain
itself?
Bring back CLI, all is forgiven.
Extra SELinux policy:
.....
# Another attempt to stop Nautilus crashing oddly.... seems to be
related to the gam_server process...
allow user_gnome_vfs_t { user_home_dir_t user_home_t user_fonts_t
user_mozilla_home_t }:dir { search getattr read };
allow user_gnome_vfs_t { user_spamassassin_home_t user_evolution_home_t
user_home_ssh_t user_gconfd_home_t }:dir { search getattr read };
allow user_gnome_vfs_t { mnt_t removable_t bin_t sbin_t var_t }:dir
{ search getattr read };
allow user_gnome_vfs_t { user_home_t user_untrusted_content_t
user_xauth_home_t user_tmp_t }:file { getattr };
allow user_gnome_vfs_t { user_home_t }:lnk_file { read };
.....
Pertinent RPM Versions:
$ rpm -q selinux-policy-strict-sources
selinux-policy-strict-sources-1.27.1-2.16
$ rpm -qf /usr/bin/nautilus
nautilus-2.10.0-4
$ rpm -q gamin
gamin-0.1.1-3.FC4
$ rpm -qf /usr/libexec/gnome-vfs-daemon
gnome-vfs2-2.10.0-5
$ rpm -qf /usr/libexec/gam_server
gamin-0.1.1-3.FC4
$
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
