Bug 184473 - Gnome trash not seeing deleted items
Gnome trash not seeing deleted items
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2006-03-08 21:38 EST by louisgtwo
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-05 11:05:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description louisgtwo 2006-03-08 21:38:41 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060306 Fedora/ Firefox/

Description of problem:
I did some investigating and found that this problem only occurs if /home
is a separate partition. I unmounted /home and created a new account, logged
in created a new text file and deleted it. All with nautilus. Trash showed
the file and was able to see it under the trash window.

Now I removed the new account and remounted /home. Did the same steps,
created a new account, logged in and create and deleted text file. Trash
did not show anything but ~.Trash had the file.

Version-Release number of selected component (if applicable):
fedora devel 03-07-06

How reproducible:

Steps to Reproduce:

Additional info:
Comment 1 Calorì Alessandro 2006-03-22 11:07:59 EST
That's happening to me too (I have /home mounted on an alternative partition).

It's a strange bug. I previously tried X.org 7.0 and GNOME 2.14 on Gentoo with
the same partitions configuration and it has never given me such problems...
Comment 2 Pavel Šefránek 2006-03-23 13:18:56 EST
I have the same problem. (/home mounted on an alternative partition too)
Comment 3 Anthony Messina 2006-03-23 18:20:08 EST
i find that i have this issue on fc4 (waiting to test with fc5), but only when i
mount /home using nfsv4.  i do not have the issue when /home is mounted using nfsv3.
Comment 4 louisgtwo 2006-03-23 19:20:04 EST
This is not an nfs share. My /home is a seperate partition. / is hda3 and /home
is hda6. I do this because if I need to reload fedora or upgrade I don't loose
Comment 5 David L. 2006-03-23 19:29:06 EST
For what its worth, I see this problem also when /home is on a separate extended
partition /dev/hda5
but not on a different machine where home is on a separate logical volume
partition /dev/mapper/VolGroup00-LogVol02
Comment 6 Pavel Šefránek 2006-03-24 10:08:46 EST
My /home is reiserfs primary patition (/dev/hda).
I also have problem with automounting this partition during booting.
dmesg says this:
kernel: audit(1142972836.240:2): avc:  denied  { search } for  pid=1142
comm="mount" name="/" dev=hda2 ino=2 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
kernel: ReiserFS: hda2: warning: xattrs/ACLs enabled and couldn't find/create
.reiserfs_priv. Failing mount.
Comment 7 Pavel Šefránek 2006-03-29 09:37:12 EST
After disabling the SELinux, the trash works OK. It must be SELinux issue.
Comment 8 louisgtwo 2006-03-30 22:27:43 EST
It is I found this on the selinux list.

 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

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?
Comment 9 David L. 2006-03-31 08:23:53 EST
I can confirm the selinux issue.

Clicking "Disable selinux protection for hal daemon" using
system-config-securitylevel also does the trick

The only AVC message related to hald that I see is this one from long ago:

type=AVC msg=audit(1142448818.838:9681): avc:  denied  { unmount } for  pid=3052
8 comm="umount" scontext=system_u:system_r:hald_t tcontext=system_u:object_r:rem
ovable_t tclass=filesystem

when it refused to unmount a flash drive. Curiously when I plugged the flash
drive back in, gnome would show the trash on the flash drive correctly. Just not
the trash in my home directory on the main filesystem.

Now that "things are unstuck" I can reenable selinux protection for the hal
daemon, and trash works ok (perhaps until I plug my flash drive in again?)
Comment 10 Rahul Sundaram 2006-04-01 12:05:05 EST
Reassigning to selinux package as per comments above.
Comment 11 Riyaz Usman 2006-04-01 19:20:18 EST
Disabling selinux for hal daemon deos the trick for me too, but that made gnome
panel disk mounter applet stop running. Any workaround ?
Comment 12 Daniel Walsh 2006-04-03 11:44:24 EDT
Fixed in selinux-policy-2.2.29-2.fc5
Comment 14 Daniel Walsh 2006-05-05 11:05:00 EDT
Closing as these have been marked as modified, for a while.  Feel free to reopen
if not fixed

Note You need to log in before you can comment on or make changes to this bug.