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.
My brain hurts!
Dave
On Wed, 2008-10-29 at 12:27 -1000, Dave Burns wrote: [...]
.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?
% mount|grep gvfs gvfs-fuse-daemon on /home/poc/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=poc)
IOW .gvfs is a mount point for the FUSE user-space filesystem daemon, so I guess permissions are being handled by FUSE. This is something Gnome apparently uses for something or other (I've no idea as I use KDE).
You might try the -mount (or -xdev) options to 'find', but that will also restrict you from crossing into other mounted filesystems.
(Does anyone else think .gvfs is a PITA?)
poc
Patrick O'Callaghan wrote, On 10/29/2008 07:04 PM:
(Does anyone else think .gvfs is a PITA?)
+1
And wondering how much grief it is going to cause me while administrating an NFS|AFS|SMB server for home directories that I need to back up. I suppose I have a little while before RHEL gets infected with this.
No Joy.
On Wed, Oct 29, 2008 at 1:04 PM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
You might try the -mount (or -xdev) options to 'find', but that will also restrict you from crossing into other mounted filesystems.
sudo find /users/tburns/ -xdev|grep gvfs find: /users/tburns/.gvfs: Permission denied
(Does anyone else think .gvfs is a PITA?)
I'm certainly moving in that direction, though there is still hope it is temporary. mahalo, Dave
Patrick O'Callaghan wrote:
On Wed, 2008-10-29 at 12:27 -1000, Dave Burns wrote: [...]
.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?
% mount|grep gvfs gvfs-fuse-daemon on /home/poc/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=poc)
IOW .gvfs is a mount point for the FUSE user-space filesystem daemon, so I guess permissions are being handled by FUSE. This is something Gnome apparently uses for something or other (I've no idea as I use KDE).
You might try the -mount (or -xdev) options to 'find', but that will also restrict you from crossing into other mounted filesystems.
(Does anyone else think .gvfs is a PITA?)
I usually throw in the -mount option to find on general principles to keep it from walking into isos or nfs mounts that might be in arbitrary places and explicitly list the mount points I want if it has to span them.
On Thu, Oct 30, 2008 at 9:33 AM, Les Mikesell lesmikesell@gmail.com wrote:
I usually throw in the -mount option to find on general principles to keep it from walking into isos or nfs mounts that might be in arbitrary places and explicitly list the mount points I want if it has to span them.
Not sure if it is a bug in find or gvfs, but -xdev and -mount do not help with this problem. Dave
On Thu, 2008-10-30 at 09:43 -1000, Dave Burns wrote:
On Thu, Oct 30, 2008 at 9:33 AM, Les Mikesell lesmikesell@gmail.com wrote:
I usually throw in the -mount option to find on general principles to keep it from walking into isos or nfs mounts that might be in arbitrary places and explicitly list the mount points I want if it has to span them.
Not sure if it is a bug in find or gvfs, but -xdev and -mount do not help with this problem.
However remounting does fix it, as mentioned earlier.
poc
Dave Burns wrote:
... Not sure if it is a bug in find or gvfs, but -xdev and -mount do not help with this problem.
I've never seen these options work, ever. I sure would like to know why, or what I'm doing wrong, it would be handy to be able to use them.
Can you just skip the .gvfs items specifically, by name, with -prune? Something like:
find / -name .gvfs -prune -o -print
<Joe
Joe Smith wrote:
Dave Burns wrote:
... Not sure if it is a bug in find or gvfs, but -xdev and -mount do not help with this problem.
I've never seen these options work, ever. I sure would like to know why, or what I'm doing wrong, it would be handy to be able to use them.
That depends on what you're trying to do with them. In order to determine whether a directory is on the same filesystem, find attempts to stat() the directory. If it doesn't have read permission, it'll spit out an error and continue, which is what it's doing in this case. There is no bug. This is the way that it's supposed to work.
If you do have read permission to the subdirectory, and the subdirectory is a different filesystem, then find will not search that directory for matching files. If you've ever seen find return results from a directory that it wasn't told to search when using -xdev or -mount, then that would be a bug. I've never seen find misbehave in that way, though.
Gordon Messmer wrote:
... If you've ever seen find return results from a directory that it wasn't told to search when using -xdev or -mount, then that would be a bug. I've never seen find misbehave in that way, though.
Well, there you go: it works as expected now.
I should know better; "Test first, complain later".
Thanks for making me check ;-)
<Joe
On Sat, Nov 1, 2008 at 6:00 PM, Joe Smith jes@martnet.com wrote:
Can you just skip the .gvfs items specifically, by name, with -prune?
man page on find -prune was not clear to me, but I tried all combos I can think of, nothing works as I'd wish:
[tburns@cod ~]$ sudo find /users/tburns|wc -l find: /users/tburns/.gvfs: Permission denied 8620 [tburns@cod ~]$ sudo find /users/tburns -name .gvfs -prune find: /users/tburns/.gvfs: Permission denied [tburns@cod ~]$ sudo find /users/tburns -prune -name .gvfs [tburns@cod ~]$ sudo find /users/tburns ( -prune -name .gvfs ) [tburns@cod ~]$ sudo find /users/tburns ( -name .gvfs -prune ) find: /users/tburns/.gvfs: Permission denied
Note that without the -prune, over 8000 lines get output. No combination including -prune ever generated a single line of non-error output. Which means I don't understand what -prune is doing, or is supposed to be doing. .gvfs is empty, so there should be lots of output even if it got pruned.
And now that I've logged out & back in and .gvfs is mounted again, I can test the other suggested workaround involving remount. This also does not work for me, though I may be giving the wrong form of mount command:
[tburns@cod ~]$ sudo mount -o remount -o exec -o suid -o rw /users/tburns/.gvfs [tburns@cod ~]$ sudo find /users/tburns/.gvfs find: /users/tburns/.gvfs: Permission denied
One of the side-effects of killing my gvfs process was that my ssh-agent died, or at least stopped working. Otherwise I'd seriously consider just killing it as the most elegant workaround.
Thanks for all the input.
Dave
Dave Burns wrote:
On Sat, Nov 1, 2008 at 6:00 PM, Joe Smith jes@martnet.com wrote:
Can you just skip the .gvfs items specifically, by name, with -prune?
man page on find -prune was not clear to me, but I tried all combos I can think of, nothing works as I'd wish:
[tburns@cod ~]$ sudo find /users/tburns|wc -l find: /users/tburns/.gvfs: Permission denied 8620 [tburns@cod ~]$ sudo find /users/tburns -name .gvfs -prune find: /users/tburns/.gvfs: Permission denied [tburns@cod ~]$ sudo find /users/tburns -prune -name .gvfs [tburns@cod ~]$ sudo find /users/tburns ( -prune -name .gvfs ) [tburns@cod ~]$ sudo find /users/tburns ( -name .gvfs -prune ) find: /users/tburns/.gvfs: Permission denied
Note that without the -prune, over 8000 lines get output. No combination including -prune ever generated a single line of non-error output. Which means I don't understand what -prune is doing, or is supposed to be doing. .gvfs is empty, so there should be lots of output even if it got pruned.
And now that I've logged out & back in and .gvfs is mounted again, I can test the other suggested workaround involving remount. This also does not work for me, though I may be giving the wrong form of mount command:
[tburns@cod ~]$ sudo mount -o remount -o exec -o suid -o rw /users/tburns/.gvfs [tburns@cod ~]$ sudo find /users/tburns/.gvfs find: /users/tburns/.gvfs: Permission denied
One of the side-effects of killing my gvfs process was that my ssh-agent died, or at least stopped working. Otherwise I'd seriously consider just killing it as the most elegant workaround.
Thanks for all the input.
-prune won't work, because as soon as find does a stat on the .gvfs directory, the error gets spit out. It's just the way gvfs is implemented. There's nothing you can do to prevent it. Sorry! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - I'm afraid my karma just ran over your dogma - ----------------------------------------------------------------------
Dave Burns wrote:
man page on find -prune was not clear to me, but I tried all combos I can think of, nothing works as I'd wish:
...
[tburns@cod ~]$ sudo find /users/tburns -name .gvfs -prune find: /users/tburns/.gvfs: Permission denied [tburns@cod ~]$ sudo find /users/tburns -prune -name .gvfs [tburns@cod ~]$ sudo find /users/tburns ( -prune -name .gvfs ) [tburns@cod ~]$ sudo find /users/tburns ( -name .gvfs -prune ) find: /users/tburns/.gvfs: Permission denied
You need to tell find what to do with files not named .gvfs:
find /users/tburns -name .gvfs -prune -o -print
And now that I've logged out & back in and .gvfs is mounted again, I can test the other suggested workaround involving remount. This also does not work for me, though I may be giving the wrong form of mount command:
[tburns@cod ~]$ sudo mount -o remount -o exec -o suid -o rw /users/tburns/.gvfs [tburns@cod ~]$ sudo find /users/tburns/.gvfs find: /users/tburns/.gvfs: Permission denied
I'm not sure what was mounted in the examples mentioned earlier. My understanding of FUSE is that the process providing the FS is the one that must perform the mount. Remounting manually should mount nothing.
Gordon Messmer wrote:
Dave Burns wrote:
man page on find -prune was not clear to me, but I tried all combos I can think of, nothing works as I'd wish:
...
[tburns@cod ~]$ sudo find /users/tburns -name .gvfs -prune find: /users/tburns/.gvfs: Permission denied [tburns@cod ~]$ sudo find /users/tburns -prune -name .gvfs [tburns@cod ~]$ sudo find /users/tburns ( -prune -name .gvfs ) [tburns@cod ~]$ sudo find /users/tburns ( -name .gvfs -prune ) find: /users/tburns/.gvfs: Permission denied
You need to tell find what to do with files not named .gvfs:
find /users/tburns -name .gvfs -prune -o -print
Will not work. As soon as the non-owner of .gvfs does a stat on the directory, the error will be spit out. find must "stat()" any item it finds to handle the remainder of the predicate and POP goes the error.
And now that I've logged out & back in and .gvfs is mounted again, I can test the other suggested workaround involving remount. This also does not work for me, though I may be giving the wrong form of mount command:
[tburns@cod ~]$ sudo mount -o remount -o exec -o suid -o rw /users/tburns/.gvfs [tburns@cod ~]$ sudo find /users/tburns/.gvfs find: /users/tburns/.gvfs: Permission denied
I'm not sure what was mounted in the examples mentioned earlier. My understanding of FUSE is that the process providing the FS is the one that must perform the mount. Remounting manually should mount nothing.
Rick Stevens wrote:
Gordon Messmer wrote:
You need to tell find what to do with files not named .gvfs:
find /users/tburns -name .gvfs -prune -o -print
Will not work. As soon as the non-owner of .gvfs does a stat on the directory, the error will be spit out. find must "stat()" any item it finds to handle the remainder of the predicate and POP goes the error.
If -name is the first predicate, and you prune matches, find will not need to stat() the directory entry:
[gordon@herald:~/tmp/findtest]$ find . -print . ./noread find: `./noread': Permission denied ./read ./read/file
[gordon@herald:~/tmp/findtest]$ find . -name noread -prune -o -print . ./read ./read/file
Gordon Messmer wrote:
Rick Stevens wrote:
Gordon Messmer wrote:
You need to tell find what to do with files not named .gvfs:
find /users/tburns -name .gvfs -prune -o -print
Will not work. As soon as the non-owner of .gvfs does a stat on the directory, the error will be spit out. find must "stat()" any item it finds to handle the remainder of the predicate and POP goes the error.
If -name is the first predicate, and you prune matches, find will not need to stat() the directory entry:
[gordon@herald:~/tmp/findtest]$ find . -print . ./noread find: `./noread': Permission denied ./read ./read/file
[gordon@herald:~/tmp/findtest]$ find . -name noread -prune -o -print . ./read ./read/file
Sorry, won't work for GVFS filesystem mountpoints. As soon as the non-owner touches the inode, the error occurs. Just a couple of tests (I'm redirecting stdout just to get rid of the stuff extraneous to the discussion):
As owner: [rick@bigdog ~]$ ls -lad .gv* dr-x------ 2 rick rick 0 2008-11-04 18:00 .gvfs [rick@bigdog ~]$ find . -name ".gvfs" -prune -o -print \ >/dev/null [rick@bigdog ~]$
As root: [root@bigdog rick]# find . -name ".gvfs" -prune -o -print \ >/dev/null find: ./.gvfs: Permission denied [root@bigdog rick]#
Note that test was on F9, x86_64. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Jimmie crack corn and I don't care...what kind of lousy attitude - - is THAT to have, huh? -- Dennis Miller - ----------------------------------------------------------------------
Rick Stevens wrote:
Gordon Messmer wrote:
If -name is the first predicate, and you prune matches, find will not need to stat() the directory entry:
Sorry, won't work for GVFS filesystem mountpoints. As soon as the non-owner touches the inode, the error occurs.
...
Note that test was on F9, x86_64.
Yep, that appears to be true for F9. It looks like the version of findutils included in F10 has been fixed in this respect, though. There's no need to touch the inode for directories which are being pruned based on their name. :)
The platform difference explains the discrepancy between your tests and mine.
Gordon Messmer wrote:
Rick Stevens wrote:
Gordon Messmer wrote:
If -name is the first predicate, and you prune matches, find will not need to stat() the directory entry:
Sorry, won't work for GVFS filesystem mountpoints. As soon as the non-owner touches the inode, the error occurs.
...
Note that test was on F9, x86_64.
Yep, that appears to be true for F9. It looks like the version of findutils included in F10 has been fixed in this respect, though. There's no need to touch the inode for directories which are being pruned based on their name. :)
Nice to hear...or is it a change in GVFS?
The platform difference explains the discrepancy between your tests and mine.
Yeah, guess so. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "Microsoft is a cross between The Borg and the Ferengi. - - Unfortunately they use Borg to do their marketing and Ferengi to - - do their programming." -- Simon Slavin - ----------------------------------------------------------------------
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@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - To err is human, to moo bovine. - ----------------------------------------------------------------------
On Wed, Oct 29, 2008 at 1:16 PM, Rick Stevens ricks@nerd.com wrote:
Dave Burns wrote:
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).
So... It is not a directory with a virtual filesystem mounted at that mountpoint? Or ... If I managed to unmount it, it would look normal?
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.
Sounds like you're saying "yep, you've got a problem." Is there a way to tell find not to go there? '! -name' and -prune did me no good.
mahalo, Dave
On Wed, 29 Oct 2008 12:27:32 -1000 Dave Burns tburns@hawaii.edu 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:
My brother ran into this issue just the other day. I just asked him for his input and he said this:
QUOTE: You can send him a message, to check whether .gvfs is a mounted filesystem (it probably is).
Why can root not access it? Perhaps because there is no read permission in the mount point?
But yeah...this gvfs stuff seems a trifle busted. END OF QUOTE
On Wed, Oct 29, 2008 at 1:34 PM, Frank Cox theatre@sasktel.net wrote:
On Wed, 29 Oct 2008 12:27:32 -1000 check whether .gvfs is a mounted filesystem (it probably is).
Yep.
Why can root not access it? Perhaps because there is no read permission in the mount point?
I created an identical directory with identical permissions, root and find have no problem with that one. I think the key was mentioned by Todd - 'the callbacks and such used when referencing it only exist in the owner's Gnome instance.' Which I take it to mean, when find (as root) calls some low-level routine, bad things happen.
So... bro has no suggestion for a workaround?
mahalo, Dave
On Wed, 29 Oct 2008 13:43:09 -1000 Dave Burns tburns@hawaii.edu wrote:
So... bro has no suggestion for a workaround?
From the message he sent me the other day when he resolved the issue on his
computer:
QUOTE: turns out that it was mounted under something...when I unmounted directory, I could modify the owner (etc) of the directory. I can also delete it; not sure whether it is a actually used by something or not. END OF QUOTE
Dave Burns wrote:
On Wed, Oct 29, 2008 at 1:34 PM, Frank Cox theatre@sasktel.net wrote:
On Wed, 29 Oct 2008 12:27:32 -1000 check whether .gvfs is a mounted filesystem (it probably is).
Yep.
Why can root not access it? Perhaps because there is no read permission in the mount point?
I created an identical directory with identical permissions, root and find have no problem with that one. I think the key was mentioned by Todd - 'the callbacks and such used when referencing it only exist in the owner's Gnome instance.'
That was me (Rick).
Which I take it to mean, when find (asroot) calls some low-level routine, bad things happen.
No, no bad things, but there's no callbacks in place for root to use to search that filesystem...they only exist in tburns' Gnome instance.
So... bro has no suggestion for a workaround?
Nope. As soon as find sees that name it'll barf. It won't stop the find, just spit out an error. You could aim stderr to /dev/null if you want. Examples:
[root@bigdog ~]# find /home/rick -name "fred" /home/rick/fred find: /home/rick/.gvfs: Permission denied
[root@bigdog ~]# find /home/rick -name "fred" 2>/dev/null /home/rick/fred
It ain't pretty, but it'll work. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Millihelen, adj: The amount of beauty required to launch one ship. - ----------------------------------------------------------------------
-
Dave Burns -
Frank Cox -
Gordon Messmer -
Joe Smith -
Les Mikesell -
Patrick O'Callaghan -
Rick Stevens -
Todd Denniston