PDA

View Full Version : .gvfs bug in Fedora 9



testlinux4ever
27th August 2008, 12:55 AM
So I am a semi-noob to the linux thing, I started with Fedora8, tried Ubuntu8, and decided on Fedora9.
I love it, but I found this bug with the /home/drew/.gvfs file.
I cannot access it or change the permissions even when logged in as root (su). I need to access this in order to run certain commands.

Does anyone know how to fix this? I have been researching forums for hours and cannot seem to find a fix.

I have rpm-4.4.2.3-2.fc9.x86_64
Kernel 2.6.25.14-108.fc9.x86_64
If you need anymore info let me know thanks.
Drew

pete_1967
27th August 2008, 01:47 AM
It's a directory with dr-x------ permissions. Normal chmod can change the permissions. (-R option for directories, `man chmod` for more detail)

testlinux4ever
27th August 2008, 02:49 AM
ok so I did a
"chmod -R 0700 .gvfs"
and then tried "chown root .gvfs"

I am still getting permissions denied with root and I couldnt make it owner.
I also did a "chmod -R 0770 .gvfs"
and still nothing.

Work with me here I am still noobish and I doing anything wrong?
I notice you are using the same flavor that I am "with better specs", did you have the same problem?
Help.

Thetargos
27th August 2008, 07:22 AM
What exactly do you want to do with the directory? And why would you want it to be root the owner? The fact that you are specifically messing with .gvfs indicates that it has something to do with virtual filesystems support in GNOME... To what end?

testlinux4ever
27th August 2008, 10:12 PM
In order for some commands to work (su) needs permissions to home/drew/.gvfs
I didnt really care about being the owner, I just wanted the thing to give root permissions (which it should have permissions to anyways).
I found the permissions by doing a 'find / -name pidof'
and it came back
find: /home/drew/.gvfs: Permission DENIED
And this is logged in as SU

Any suggestions? It is a known bug but I cannot find a fix to it NEwhere lol

A.Serbinski
27th August 2008, 11:07 PM
I don't see how this is a bug.
You're using gvfs to mount some filesystem, presumably a remote NETWORK filesystem.
In order to have permission to read, write, or anything else, the user that you are using to log in to the remote system MUST HAVE SUCH RIGHTS.

In addition, your LOCAL ROOT is not the same as the REMOTE ROOT and therefore has no privileges whatsoever on the remote system. gvfs is doing exactly what it should do and preventing access to ALL users besides the one who actually has permission to access it.

If you mount a remote filesystem with some user, lets say "sam", then you do NOT get permission to portions of that filesystem unless "sam" has such permissions.

testlinux4ever
28th August 2008, 01:42 AM
I really appreciate the assistance but who said anything about a remote host?
It is a laptop.
I cannot run ifconfig, because of this issue.
if I do a 'find / -name ifconfig'
I get the same permission error as listed above.

http://www.linuxforums.org/forum/linux-security/127743-root-permission-denied-while-luser-can-remove-dir.html
This is another person who has had the issue.
I dont like to post with out doing a LOT of research.
Thanks,

A.Serbinski
28th August 2008, 02:05 AM
YOU did. What do you think gvfs does? You asked a question about gvfs, now it turns out that your question had nothing at all to do with gvfs, but rather file permissions in general.

If you're running a command like "find", it is not going to scan through directories for which it lacks read permissions and will spit out an error when such is encountered. THIS DOES NOT MEAN that the program isn't working. 'find' will still go through all the other directories that it DOES have permission to read.

Yes, it will spit out a bunch of "permission denied" errors, but those are only to tell you that there are places where it has no permission to read. It will still output the result of your query.

If you just don't want the errors showing up, slap on a 2>/dev/null "find / -name ifconfig 2>/dev/null"

And again, this is NOT a bug. You certainly CAN run ifconfig as doing so is absolutely in no way related to this message.

Wayne
28th August 2008, 02:19 AM
If you want to run ifconfig after issuing the su command then you have to use the full path to the executable. If you don't want to do that then you have to use:

su -

su space dash, then give the root password before typing ifconfig

Wayne

testlinux4ever
28th August 2008, 02:32 AM
Ok dude,
I cannot run ifconfig
I get a 'command not found'
so in fact the program DOESNT WORK.
With all due respect, dont just reply to flex.
If you are going to help I appreciate it, if not dont waste my time.
I dont mind the errors showing up because that is why I ran the command, to see if it was a PATH error or in this case a Permissions error.
And I am a noob at this OK.
BTW I am doing this as SU, which SHOULD have access to .gvfs

testlinux4ever
28th August 2008, 02:33 AM
ty Wayne I am doing just that

bob
28th August 2008, 02:35 AM
$ su [B]- <don't forget the minus sign!
Password:
[root@localhost ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:D4:C6:E0:DD
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::213:d4ff:fec6:e0dd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:69370 errors:0 dropped:0 overruns:0 frame:0
TX packets:63583 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:41323854 (39.4 MiB) TX bytes:10897936 (10.3 MiB)
Interrupt:23 Base address:0x8000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:7382 errors:0 dropped:0 overruns:0 frame:0
TX packets:7382 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2577361 (2.4 MiB) TX bytes:2577361 (2.4 MiB)

testlinux4ever
28th August 2008, 02:43 AM
Wow you are awsome I feel dumb now I never put the - in after the su and that was my problem
I didnt know you HAD to do that
Thanks so very much.
To Wayne and BOB
I really appreciate the help

testlinux4ever
28th August 2008, 02:48 AM
again thanks all my programs I wanted to try in bash are working now

Thetargos
28th August 2008, 04:08 AM
Actually the problem you had with ifconfig relates to the fact that admin programs are usually located under /sbin and /usr/sbin/, those paths are not part of the PATH variable of regular users. you can still use these commands if you use their full path, with the restrictions they may have from not being run by UID=0 (root), for example:



/sbin/ifconfig
To check upon the network status of the different interfaces



/sbin/lspci
To check upon the PCI bus and oder of devices (running any more verbose mode would require root's privs, though)



/sbin/lsusb
To check those devices in the USB bus.

And many others.

Edit

Some other useful programs that can be run as a regular user to find out stuff or to maximize use of the system.



/usr/sbin/lsof
To find out what programs are accessing what parts of the filesystem at any one time (ever wanted to unmount a CD ROM drive, only find out you couldn't and didn't know what program was accessing it?)



/usr/sbin/alternatives
This is indeed very useful, though limited with regular user privs, as you can't alter anything, but you can check things up. This program is used to be able to have multiple different versions or types of the same application, but only have one at a time active, and you can configure multiple instances, for example, is how Java has been managed in Fedora since as far back as Core 4 (Stentz), and is how you can leave OpenJVM, GCJ and Sun Java installed on the system and only use one default JVM system-wide or have a launcher program use a particular version.

A.Serbinski
28th August 2008, 08:15 PM
BTW I am doing this as SU, which SHOULD have access to .gvfs
No, it SHOULD NOT.
gvfs is for local users mounting remote network shares. Things that the local ROOT should NOT have access to.


Think about it like this:
You run an office network server and have a user, lets call him "john", who has read access to all of the files on your system. John is at a client's office and needs to access something on the server, the client graciously offers him the use of their systems. You store sensitive information of your server that you don't want the administrator of the client's network to have access to, but to which John must have access. gvfs is protected, even from root, because it presents information that ONLY the one person (who is not root) should have access to.

testlinux4ever
29th August 2008, 12:46 AM
Targos,
Thanks for all the cool tips I appreciate the cool input.

Serbinski,
Maybe it wasnt the .gvfs thing because now I can use the commands I wanted to access (I just have to login using {su -}. But if I do the find thing I am still getting permissions denied. So I dont know I am just glad I can go on with my learning. I understand what you were saying about the remote thing too. sounds good.
Thanks to all
Respectfully,

danielito
29th August 2008, 01:47 PM
Good morning people.

I'm sorry to bother you, but I had a problem that I think it might be related to this thread. I don't want to bump mine, so it will be really great for me if anyone could have a look at it. It's here (http://forums.fedoraforum.org/forum/showthread.php?t=189361)

Thanks a lot in advance for your help.

techmum
30th August 2008, 07:19 PM
guys,

~/.gvfs is a mounted virtual file system. Before you can change ownership and/or permissions, you need to unmount it.

Hence, in my case as user techmum >

umount /home/techmum/.gvfs

Once you have done that you can change the ownership and/or permissions.

After you have changed those, I suggest you reboot.