Empty trash in Gnome

[Dawid Gajownik]

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

[Stephen Smalley]

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)?

[Dawid Gajownik]

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

[Stephen Smalley]

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.

[Bob Kashani]

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