Re: OT: find command permissions: how to exclude dir?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Burns wrote:
I have a cron job that runs 'find /' as root, keeps blowing up when
encountering ~/.gvfs in my home dir. Permissions are set like so:

 ls -la ~/.gvfs
total 4
dr-x------  2 tburns isys    0 2008-10-13 07:43 .
drwxr-xr-x 73 tburns root 4096 2008-10-24 11:49 ..

As owner of dir, no problem:
 find /users/tburns  ! -name .gvfs |grep gvfs

As root, boom:
sudo  find /users/tburns  ! -name .gvfs |grep gvfs
[sudo] password for tburns:
find: /users/tburns/.gvfs: Permission denied

When I create another similar directory, same permissions, root has no
problem with it. But note ***the copy has a different file size
(original size=0, copy size=4096)***:
[tburns@cod ~]$ cp -pr .gvfs .gvfscopy
[tburns@cod ~]$ ls -la .gvfscopy
total 8
dr-x------  2 tburns isys 4096 2008-10-13 07:43 .
drwxr-xr-x 76 tburns root 4096 2008-10-29 10:56 ..
[tburns@cod ~]$ sudo  find /users/tburns/.gvfscopy
/users/tburns/.gvfscopy


.gvfs is using some secret sauce that I don't understand to prevent
root from accessing it.  Is there some ACL stuff going on here?
(getfacl results are boring.) File locking? (lsof says it is not
open.) Corruption? How can it be that root is denied? I wonder what
would happen if I deleted .gvfs and recreated it manually with
identical permissions?

I tried googling gvfs and permissions, got many many irrelevant hits.
Some hits described a similar problem, but always veer off to a
workaround for their specific situation, no general solution. Please
at least give me a hint what to do or what to google for.

.gvfs is a virtual filesystem and doesn't follow normal filesystem
semantics (witness the fact the size of it is zero).  find can't
traverse it if you aren't the owner as the callbacks and such used when
referencing it only exist in the owner's Gnome instance.

Making a copy of it creates a real, honest-to-goodness directory with a
non-zero size, which find can happily traverse even if you aren't the
owner since it's a real file/directory, not a virtual one.

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                      ricks@xxxxxxxx -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-                   To err is human, to moo bovine.                  -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux