Hi! My friend noticed that with SELinux in enforcing mode ~/.Trash is full of the files but he cannot remove them -- clicking on trash icon placed on the desktop shows empty directory.
I reproduced this bug on my machine (FC5, selinux-policy-targeted-2.2.25-2.fc5, Gnome 2.14) and found this avc message:
Mar 30 19:19:47 X kernel: audit(1143739187.507:65): avc: denied { getattr } for pid=1810 comm="hald" name="/" dev=hda6 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
Using audit2allow I created kosz.pp module and this resolved the problem (you need to reboot or restart haldaemon service). Here's the content of te file:
[root@X ~]# cat kosz.te module kosz 1.0;
require { role object_r; role system_r;
class dir getattr;
type hald_t; type home_root_t; };
allow hald_t home_root_t:dir getattr; [root@X ~]#
Maybe default policy should be fixed?
Thanks, Dawid
On Thu, 2006-03-30 at 20:44 +0200, Dawid Gajownik wrote:
Hi! My friend noticed that with SELinux in enforcing mode ~/.Trash is full of the files but he cannot remove them -- clicking on trash icon placed on the desktop shows empty directory.
I reproduced this bug on my machine (FC5, selinux-policy-targeted-2.2.25-2.fc5, Gnome 2.14) and found this avc message:
Mar 30 19:19:47 X kernel: audit(1143739187.507:65): avc: denied { getattr } for pid=1810 comm="hald" name="/" dev=hda6 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
Using audit2allow I created kosz.pp module and this resolved the problem (you need to reboot or restart haldaemon service). Here's the content of te file:
[root@X ~]# cat kosz.te module kosz 1.0;
require { role object_r; role system_r;
class dir getattr; type hald_t; type home_root_t;
};
allow hald_t home_root_t:dir getattr; [root@X ~]#
Maybe default policy should be fixed?
How does that help, as it would only allow hald to stat(2) /home, not to search it or descend to the user's home directory at all? Why is hald involved in looking at the user's trash directory (pardon my ignorance)?
Dnia 03/30/2006 08:53 PM, Użytkownik Stephen Smalley napisał:
How does that help, as it would only allow hald to stat(2) /home, not to search it or descend to the user's home directory at all? Why is hald involved in looking at the user's trash directory (pardon my ignorance)?
Well, I don't know :) I'm a KDE user and I know nothing about Gnome internals. This link gave me some tips → http://bugzilla.gnome.org/show_bug.cgi?id=171073 (search for hal).
~/.gnome/gnome-vfs/.trash_entry_cache is not updated correctly without updated SELinux policy.
Regards, Dawid
On Thu, 2006-03-30 at 21:10 +0200, Dawid Gajownik wrote:
Well, I don't know :) I'm a KDE user and I know nothing about Gnome internals. This link gave me some tips → http://bugzilla.gnome.org/show_bug.cgi?id=171073 (search for hal).
~/.gnome/gnome-vfs/.trash_entry_cache is not updated correctly without updated SELinux policy.
Ok, per that bugzilla, nautilus asks hald for the set of mounted volumes, so that explains why hald just wants to stat /home as an existence test. So hald actually needs getattr to all mounted directories.
On Thu, 2006-03-30 at 14:18 -0500, Stephen Smalley wrote:
On Thu, 2006-03-30 at 21:10 +0200, Dawid Gajownik wrote:
Well, I don't know :) I'm a KDE user and I know nothing about Gnome internals. This link gave me some tips → http://bugzilla.gnome.org/show_bug.cgi?id=171073 (search for hal).
~/.gnome/gnome-vfs/.trash_entry_cache is not updated correctly without updated SELinux policy.
Ok, per that bugzilla, nautilus asks hald for the set of mounted volumes, so that explains why hald just wants to stat /home as an existence test. So hald actually needs getattr to all mounted directories.
I can confirm this. Dan, can you fix this please:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184473
Bob
selinux@lists.fedoraproject.org